I've worked with this approach for the past year: we have a "release" named branch, we deploy that, run all automated tests in production, wait a couple of hours for feedback including customer support, then merge it to master.

This means master is a history of proven stable builds. And in an emergency you don't have to think about what to roll back to, it's by default master.

It's just a convention, it does not have any real benefits or downsides. You could do the same with another branch named stable, or with tags.

> a record of every version that was seen by actual users

This is covered by the release branches and also by the CD pipeline.