Story: Act inside a tenant

A system administrator can enter one tenant on purpose, see on every screen that they are acting in it, read its data through the same reads its own members use, and leave. Row-level security does the scoping from the session's token, so no read takes a tenant parameter and no cross-tenant subject is needed. The hand-written refdata.v1.parties.list-of-tenant read is removed.

• The journey Act inside a tenant is written first, with its wireframe.
• Entering a tenant needs iam::tenants:impersonate, refuses the system tenant as a target, and is recorded in the audit trail.
• While acting in a tenant, every screen says so and offers the way out; leaving returns to system administration.
• The tenant's parties are read with refdata.v1.parties.list in the tenant's session, paged, with no fixed cap.
• refdata.v1.parties.list-of-tenant, its service, handler, tests and shell command are removed.
• Every new behaviour is proved by a test, and each screen was read against the running deployment.

• A tenant's data is read from inside the tenant, in a session scoped to it; no read takes a tenant parameter, and row-level security scopes the ordinary reads from the token.
• Inside a tenant, data is read only. The token carries only the read permissions the administrator holds, and the BFF refuses every change before the route runs. A system administrator changes a tenant only by deleting all of it.
• Entering checks iam::tenants:impersonate against the database, because a person's token carries no permissions.
• The tenant session is not refreshed; when it lapses, the browser returns to the system session without a sign-in.
• The client owns the entered tenant and its outside token; the BFF session reads from it, so there is one source of truth.
• Entering and leaving are recorded in the entered tenant's own audit trail.

All tasks done.