Fix the self-authorization shortcut in hasRole #544

Phase 1 — Foundations. A behaviour-preserving authz refactor; must land before the Service Account type.

Today
hasRole returns true before checking any role whenever the caller's own account id equals the account being acted on (authz.ts). The same self-equals-target pattern appears 17 times in that file against accounts and products.

For a person this is harmless — you may act on yourself.

Do
Require a real role check even when the ids match, or exclude service accounts from the shortcut — while preserving every path where an individual manages themselves.

Done when

• A test proves a service account cannot edit its own flags, profile, or memberships.
• Every existing individual-managing-themselves path still passes.

Why first
A service account has its own account id, so until this is fixed it authorizes itself for anything scoped to itself — its own profile, its own memberships, its own data connections. The owner cap has the same hole; one fix serves both.

It does not reach the admin flag: putAccountFlags ignores its account argument and denies every non-admin unconditionally.

Watch
The shortcut is load-bearing. canManageAccount has no self-check of its own and relies on it for "an individual account managing itself"; canManageAccountDataConnections builds on that. Narrow the shortcut naively and every user loses their own profile and data-connection pages. Blast radius: 27 hasRole call sites, 132 isAuthorized call sites, and a 3,780-line authz.test.ts.

Part of #491.