With various degrees, all companies are dysfunctional in one way or another (and some more than other), but everyone thinks they are doing fine and dandy. Of course they're not.
The same applies for Agile. Everyone now is "doing" Agile (mostly the Scrum variant, or SAFe if you are "doing" Agile at scale) and everyone thinks they are doing fine and dandy. Of course they're not.
Agile is not something you do, it's a mindset, it's something you are. It's not an ISO standard that lays down a formula for you to apply, or a process with well defined steps that you need to follow... and presto, result guaranteed.
To be Agile, you have to think. And many don't want to think.
To be Agile, you have to change. And many don't want to change.
They reach out for some canned solution (e.g. Scrum, SAFe) and follow that like zombies crawling after the smell of blood. They don't think about what they are doing, and they don't look at themselves doing it.
Agile is about "inspect and adapt", but I rarely see people inspecting or adapting.
For Agile to be successful, upper management needs to support the adoption and create an environment that is conducive to Agile. But they don't. Because they don't want to change (they still plan yearly, or want a six months detailed roadmap in the form of a Gantt chart, or requirements documents of 100 page each signed by three different managers for approval, and deadlines set to a specific date in the future by someone who's not even involved in the development of the product, etc.) and they don't want to think (Is what we are doing working? Yes? No? What are we doing well? What are we doing not so well? How do we know how to distinguish between the two, etc).
Agile has unfortunately become a buzzword and everyone is now using this word (together with many other changes in vocabulary with new words like Scrum Master, Product Owner, Squad, Chapter, Epic, User Story, Story points, etc). But that means squat if you are stuck in a rigid mindset and you don't really want to change.
So what you are describing looks dysfunctional to me. And no matter what words the company wants to use to describe what they are doing, that doesn't make it less dysfunctional.
You are not describing Scrum, or Agile for that matter. And no, user stories should not be delivered orally.
You can start a conversation orally, but then you need to capture more details in one form or another to share with others (you gave some examples) simply because people forget, or they understand things differently. And if everything happens by word of mouth, even if by some miracle you build what's needed, the code will be the only source of written information and not many can read code (especially since you mention 50% managers within the team, which is another weird setup for something deemed Agile).
Like I said, to some degree or another, all companies are dysfunctional in their Agile implementation. You just have to work for those that are less so than others. Sometimes you can find out how dysfunctional they are from the interview, by asking the right questions. But sadly, many times you only discover how dysfunctional they are after you've worked there for a while.
EDIT: after the question was updated.
How much detail should be written and explicit? Or is it entirely reasonable that all details remain implicit, stored in the collective memory of the team?
It depends on the story. Something like "As a user I want to login into the application..." will probably sit as a one liner, where the details can just be something like "use industry best standards". On the other hand, a feature that requires to calculate insurance premiums with discounts and loyalty bonuses will probably need very detailed specifications, where you spend some upfront time to clarify things, write them down, and make sure they are properly understood before you even write a line of code.
Agile says, "Working software over comprehensive documentation", so documentation in Agile is build as needed (or just in time), and with just enough details to support shared understanding of what needs to be built. Some features need less details before building them, some will need more. There isn't a rule where to draw the line. But keep in mind that producing more than needed can cause waste, since you either abandon the documentation once it has served its purpose, so you want to invest less in this type of activity if you trash it; or you have to keep it up to date while building the product, and if there is a lot of it, it will take a lot of effort to keep it updated). So a lot of common sense needs to be involved here; you need to think, experiment with things, inspect, and adapt.
Scrum boards are often depicted as having only sticky notes. And presumably, those sticky notes are trashed when the sprint is done. So do such teams maintain documentation separately, or have none at all?
Those are "placeholders" to track and manage the activities in the current Sprint. The sticky notes are thrown out at the end of the Sprint, but they don't retain all the conversation that took place, or all the details and material gathered or built to support that conversation and shared understanding. So yes, the documentation is stored separately. Many teams use tools like Jira or Confluence which retain the details and keep track of them. Even if you have a physical board, the sticky notes usually contain just a short title and an ID to the Jira issue that you can use to find out all the other details.