fix(auth): resolve service-principal created_by via shared identity store

[Diego Colombo (colombod)]

Problem

In Entra auth, the service/app (managed-identity) token path derived created_by from a fallback chain — service_identities[oid] → appid → azp → oid. When the token's oid was not in the service identity map, the chain fell through to a raw GUID, so ingested data was silently attributed to a machine identifier instead of a contributor handle. That produces a phantom "contributor" in the graph, and nothing errors or logs.

The user-token path already 403s on an unmapped oid. Only the service path failed soft.

Fix — align the service path with the user path

auth.py — created_by for a service token now comes solely from the identity map. An unmapped oid is a 403 naming the principal; there is no appid / azp / oid / app_displayname fallback.

main.py — one shared IdentityStore serves both user and service oids. Entra object IDs are disjoint across users and service principals, so a single oid → contributor map covers both. The resolver receives the store's live flat_dict as both maps, so a mapping added via PUT /admin/identities/{oid} takes effect immediately, with no restart.

config.py — service_identities may be empty; an empty service map is the normal bootstrap state, not a startup error.

Startup warning — service_identities seeds the shared store on first boot only; once the store file exists, config is never re-read into it. Setting it on an already-deployed server therefore has no effect, and the only symptom would be a 403 whose message points at the administrator rather than at the ignored config. Boot now logs a WARNING naming any ignored oids and pointing at PUT /admin/identities/{oid}.

No new admin route and no new record fields — service identities are managed through the existing PUT / DELETE / GET /admin/identities endpoints with the existing record shape.

Documentation

AGENTS.md, README.md, docs/entra-auth-setup.md, docs/identity-management.md, docs/azure-deployment.md, docs/architecture/README.md, docs/m2-auth-acceptance.md, plus the three auth architecture diagrams re-rendered.

docs/m2-auth-acceptance.md needed particular care: the live-token acceptance gate asserted created_by == appid, which targeted the fallback chain this PR removes. Those assertions are marked superseded, and re-running that gate now requires the caller's oid to be mapped first.

Testing

• pytest -m "not neo4j and not integration" (the CI selection): 1819 passed, 2 skipped
• pyright on context_intelligence_server/: 0 errors
• ruff format --check on all changed Python files: clean

New coverage: fail-loud 403 and no ingest on an unmapped service token; service-oid resolution through the single shared store; the resolver's user map, service map and the store's flat_dict being the same live object; empty service_identities booting cleanly; and the ignored-config startup warning (verified failing without the warning and passing with it).

Migration

⚠️ Behavior change: an unmapped service principal now receives a 403 instead of silently ingesting under a GUID.

Before, or immediately after, deploying — map the service principal's oid. Key on the service principal's object ID, not its appId:

PUT /admin/identities/{oid}
{"id": "<contributor>"}

This is the same call used to onboard a user, and it takes effect without a restart. Config service_identities will not work for this on a server whose identity store file already exists — the startup warning added here will say so explicitly.

Historical data: existing mis-attributed nodes are write-once (ON CREATE SET) and will not self-heal. They can be remapped with a one-off data fix once the mapping is in place — no code change required.