The human has a place on the floor but no body — make the owner a first-class character #192

The human already has a place on the office floor. What they don't have is a body.

I went looking for an existing owner/user entity before writing this, and the interesting part of the answer is that the hole is already human-shaped — three separate features point at a person who isn't drawn.

What already exists (verified, not proposed)

• 'human' is a routable message endpoint. OfficeFloor.tsx:1603-1605 defines humanPos as the entrance tile, and envelopes addressed to 'human' fly there. Escalations already have somewhere to land.
• The ASK ME board (OfficeFloor.tsx:1129-1147) hangs on the wall: one lilac note per open question parked for the human, pulsing while anything waits, click-through to the Command Center's human tab.
• Agents wait at the door for you. The comment at OfficeFloor.tsx:1509-1513 is explicit that the door is "reserved for agents that need the human" — the waiting state deliberately keeps agents at their desks so the doorway means one thing.

So the app already models the human as a destination, a noticeboard, and a reason to queue by the entrance.

What doesn't exist

• No human in the cast. OFFICE_CAST (cast.ts:27) is fifteen fictional characters; OfficeCharacterName (cast.ts:12) is a closed union; every agent must map to one of them (store.ts:34).
• Nothing the human does is attributed to a body. Answering an ASK ME question, approving, pausing an agent, typing into a terminal — all of it happens, and none of it is visible on the floor as someone doing it.

The result is an office where fifteen people work for someone who is never in the room.

The ask

The owner as a first-class character:

• Walks in the front door when they answer a question or come back to the app, rather than mail arriving at an empty doorway.
• Has their own desk — the corner office is the obvious joke and the obvious right answer — instead of a pool seat.
• Gets credit for what they do. ASK ME answers, approvals, pause clicks, terminal presence attributed to their character.
• Envelopes fly to them, not at the door. posFor('human') returns their desk once they have one, and the door goes back to being a door.

Design notes, including the awkward one

• The closed union is the real decision. OfficeCharacterName is exhaustive by design and the whole cast pipeline (portraits, scene frames, seat claiming) keys off it. An owner either joins that union — and inherits everything, including the character-fallback behaviour in Hire import always loads the Jim character when the manifest has no 'character' field #191 — or becomes a separate entity type that the floor renders alongside agents. I'd lean to the second: the owner is not an agent, doesn't take a pool seat, doesn't get a status glyph, and shouldn't be selectable as a hire's character by accident.
• A new character is a recipe, not an asset. Per cast.ts's own header, portraits and scene sprites are custom-drawn from per-character recipes in portraitArt.ts — so this doesn't need spritesheet work, which makes it cheaper than it sounds.
• Presence needs a definition. Suggestion: the owner is at their desk when the app has focus or they've acted recently, walking in on an answer, and the desk simply sits empty otherwise. An owner character permanently idle at a desk would be less informative than no character at all.

Related: #191 (character fallback when a hire has no character field) touches the same union. #164 (floors/departments) and #103 (other themes) are adjacent but independent.

I haven't prototyped any of this — the file references above are read, not run.