feat(auth): per-service team scope

[TartanLeGrand]

What

Enforces the per-service team scope that scope_all / scope_services on teams already stored but never applied (PR 4 of the SSO series). A caller now only sees and writes the events, locks and catalog entries of the services of their teams. Backend and docs only: no proto, no generated code, no web change.

Commits:

• feat(auth): add service scope helpers
• feat(auth): validate team scope payloads
• feat(auth): scope events by service
• feat(auth): scope locks by service
• fix(auth): do not write to out-of-scope events when unlocking
• feat(auth): scope the catalog by service
• test(auth): guard every RPC and HTTP route against unscoped access
• test(auth): cover service scope end to end through the gateway
• test(auth): assert stored state after denied scope requests
• docs(auth): document the per-service team scope
• fix(auth): count team scope service names in characters
• docs(auth): warn that scope needs restricted anonymous access

Semantics

Full rules in docs/AUTHENTICATION.md, section "Service scope".

• A user gets the union of the scopes of their teams, all as soon as one team is all; a team API key gets its team scope, re-read on every request. Global keys, anonymous callers and Administrators are all.
• Lists, search, today, stats and monthly stats of events, locks and catalog (and version compliance) are filtered in the Mongo query.
• Get, create, update, delete, unlock, changelog, Slack id, versions and dependencies on an object outside the scope answer 403 (PERMISSION_DENIED) naming the service; there is no 404 masking.
• An update checks both the stored and the new service, so an object cannot be moved into or out of the scope.
• An object without a service is only visible and writable with scope all; a user who belongs to no team has an empty scope and sees and writes nothing.
• Version compliance treats a deliverable outside the scope as absent; a catalog entry in scope is returned whole, dependency names included.
• A lock cannot be linked to an out-of-scope event; unlocking or completing an event still releases the in-scope lock without writing to the out-of-scope event.
• Not scoped: custom links, Homer, /config.js, Swagger, AuthService (guarded by access:manage).
• Team API: scopeAll: true with services is refused with 400, as is a list of blank services; names are trimmed and deduplicated (500 services of 128 characters max); Administrators cannot be restricted. GET /auth/me returns scopeAll / scopeServices.
• Anonymous access caveat: the scope only isolates teams once anonymous access is restricted. Anonymous callers are all, and while AUTH_ANONYMOUS_PERMISSIONS keeps its transitional default (every permission except access:manage), a restricted user or API key can read and write outside its scope by not sending its credential. Set AUTH_ANONYMOUS_PERMISSIONS= (empty), or read-only permissions (anonymous reads then stay unscoped). Documented in docs/AUTHENTICATION.md.
• Upgrade effect: a team already stored with a list of services becomes restricted when this version is deployed; teams created by the bootstrap or without services stay all.
• Refusals are counted in the existing tracker_auth_requests_total{result="scope_denied"} metric.

Checks

• go build ./..., go vet ./...: clean. gofmt -l: only the pre-existing internal/utils/utils_test.go.
• go test with packages run serially against a MongoDB 7 container: all packages ok (server 75s). -race on ./server/, ./internal/stores/ and ./internal/auth/...: pass (counts of PASS lines include subtests).
• golangci-lint run ./...: 0 issues. gosec -exclude=G103,G115 -exclude-generated ./...: 0 issues. govulncheck ./...: 0 vulnerabilities in called code.
• Existing tests are untouched: git diff origin/main --stat -- '*_test.go' shows 10 new files, additions only.
• A guard test lists every gRPC method and every HandlePath route and fails when one is neither scoped nor explicitly exempted.
• Manual end-to-end against a real serv with a dedicated database: two teams scoped to service-a and service-b, two local users, a team-a API key. The user and the key see only service-a events, locks, catalog, stats and version compliance; get, update, delete and create on service-b answer 403; moving an event to service-b answers 403 and leaves it unchanged; a deployment start takes the service-a lock and success releases it; widening team-a to service-b applies to the same key on the next request and narrowing it back restores the 403; GET /auth/me reports the scope; the admin sees everything; scope_denied is counted for both user and API key principals and authz denied is logged.

Notes for reviewers

• The store List, Search, count and aggregate functions now take an auth.Scope. Open PR feat(integrations): record deployments from GitLab and Flux webhooks #209 (deploy integrations) will need auth.ScopeAll() in its calls at rebase, and must read the stored lock in the UpdateLock RPC before calling its core. Its webhook routes must be added to the guard table (httpRouteSites).
• Two new indexes: idx_lock_service and idx_catalog_name.
• The HTTP half of the guard test only sees HandlePath calls under server/ and cmd/.
• Users created by an admin carry mustChangePassword, but the backend does not enforce it (only the web UI redirects), so the manual run did not need a password change.

Follow-ups

• Team scope selector in the web UI (after feat(web): login page, auth context and admin pages #201). Until then the team dialog of feat(web): login page, auth context and admin pages #201 shows the scope read-only and sends it back unchanged when a team is edited: create and change restricted scopes through the API.
• On event creation, related_id can reference an out-of-scope event, which reveals that it exists and when it was created.
• The pre-existing catalog indexes are created on the wrong collection.
• The backend does not refuse RPCs for a session flagged mustChangePassword (only the web UI redirects): worth a separate hardening.
• PR 5 (MCP server API key) will inherit the scope of its team.

Refs #196