A portal session names a person, not whoever enrolled

Remote access used to collapse every portal session onto the account that
performed the enrolment. That was the only thing it could do while nothing
here knew who was at the other end, and it is why letting a second person
in meant handing them the first one's account.

`user.portal_sub` is where a portal identity meets a local one: set for the
enrolling superuser at enrolment, and for each person a superuser admits
afterwards through Settings -> Remote access -> Add remote user. The code
they type comes from the newcomer's own portal account, and it is redeemed
against the hub with this installation's tunnel credential rather than with
a portal session, so being let in is not itself the power to let others in.
The account created is never a superuser, which closes the same door from
this side.

A proxy token now resolves through that mapping and nowhere else. An
identity nobody mapped resolves to no user rather than falling back on the
enroller, so deleting the local row under Admin -> Users is the whole of
the revocation: it bites on a credential already in flight, and it does not
wait on the portal being reachable to be told. Telling the portal is best
effort for exactly that reason.

The cost is stated where it lands, in DEPLOY.md: an installation enrolled
before this has no mapping, so its owner reconnects once with a fresh code.
Panels and the health summary still act as the enrolling account - neither
of them is a person, and neither gained a way to name one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ROADMAP.md

@@ -324,6 +324,22 @@ Shares components with the admin view. See `docs/architecture/structure.canvas`
       credential is traded for the hub's cookie rather than carried in the URL a
       year-long token must never sit in. What is waiting on a code is named
       before anyone approves it
+- [x] Remote users: a portal account other than the installation's owner reaches
+      it, as a local user of its own. The mirror of the claim code — the person
+      wanting in mints a code on their portal account, and a superuser here
+      redeems it, so admission is a local decision made by someone who already
+      had the right to grant remote access at all. The installation redeems it
+      holding its tunnel credential rather than a portal session, which is what
+      stops an admitted user from admitting anyone else; the account they get is
+      never a superuser, so the same is true from this side. `user.portal_sub`
+      is where a portal identity meets a local account, set for the enrolling
+      superuser at enrolment and for each admitted user after. A proxy token now
+      names a person rather than resolving to whoever enrolled, and an unmapped
+      identity resolves to no user — so deleting the local row is the whole of
+      the revocation, immediate even against a credential already in flight and
+      even when the portal cannot be reached to be told. The hub's `_authorize`
+      grew one member lookup beside the owner comparison, which is the only
+      thing that changed about the tunnel
 
 ## Phase 5 — Website and docs