rescue: unpushed work from station01 worktree (idp-fed-harden-work)

[andrei-hasna]

Rescued unpushed work from a station01 worktree

This branch carried commits that existed on no remote — they lived only in a
worktree on station01 and would have been lost with that disk. Pushing them is a
rescue, not new work.

Found by the station01 worktree census (worktree-fleet-cleanup). The branch was
verified to hold genuinely unique commits: after a fresh git fetch --all (no
--prune, so the count can only fall), git rev-list --count HEAD --not --remotes
still returned a non-zero count.

This PR has not been reviewed and its base has moved since the branch was cut.
Treat it as a recovered artifact to triage, not as a ready-to-merge change. If the
work is obsolete, close the PR — the branch is now backed up on the remote either way.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[andrei-hasna]

[REVIEW] NO_GO — #205 @ 7ae4de2 — lens: correctness+security+gates, reviewer unresolved-account006 (1 of 1)

What I ran

• git rev-parse HEAD origin/main — exit 0. Head was 7ae4de21ba03cfaf6912dffaa3934e171c21a073; freshly fetched origin/main was 6bf68314eedf6636e92e59989ae8fcba8c968402.
• git log --oneline origin/main..HEAD — exit 0.
• git diff origin/main...HEAD --stat — exit 0: 26 files, 2,870 insertions, 64 deletions.
• Full git diff origin/main...HEAD -- <file> for every changed file — exit 0.
• bun install — exit 0. Setup only; this is not the repository test result.
• bun run test — exit 0: 4097 pass, 154 skip, 0 fail, 19654 expect() calls; 4,251 tests across 272 files.
• git status --short — exit 0 with no output; setup and review left the worktree clean.
• This repository declares no standalone typecheck script, so no typecheck was invented or run. No separate build gate was present in the supplied repository gate set.

What I read

I read the complete diff of all 26 changed files and surrounding source for the self-hosted request dispatcher, API-key tenant binding, IdP JWT/JWKS verification, auth service/store, PostgreSQL migrations, operator CLI/API surface, OpenAPI and generated SDK contracts, hermetic test wrapper, and all new or changed tests. I also traced the authorization decisions through request-context resolution, tenant-scoped stores, operator checks, and the accepted IdP authority ADRs.

Blocking P0/P1 findings

• P1 — current head cannot safely integrate with current main, and its migration identity is stale. GitHub reports this PR as CONFLICTING, and a local git merge-tree against the exact merge base reproduces conflicts in the migration registry, migration assertions, generated contracts, and related guard inputs. Current main already contains the equivalent IdP hardening from PR fix(server): tenants-IdP federation hardening — send authority, JWKS revocation honesty, operator surface, claims binding, (sub,tenant) keying, tid drift #159 and assigns 0022 to the events enum check, 0023 to webhook idempotency, and 0024 to IdP multi-grant. This head still assigns IdP multi-grant to 0022, with tests and guard hashes pinned to that stale sequence. Seven of ten head commits are patch-equivalent to current main; the remaining three are the stale migration/test/guard variant. A textual conflict resolution that retained this head's numbering could duplicate or skip a production migration. Remedy: close this recovered duplicate, or rebase and deduplicate it while preserving current main migrations 0022/0023 and IdP multi-grant as 0024, then review the new head.

I found no separate reachable P0/P1 tenant-isolation bypass, token-validation allow path, secret exposure, or session-integrity defect in the isolated feature diff. The blocking verdict is the concrete required merge/migration gate failure above.

Non-blocking follow-ups

• P2: the new operator grant/revoke/restore path changes durable IdP mappings but does not emit a durable mapping-lifecycle audit record; the accepted ADR calls these mapping changes auditable. Request-time IdP allow/deny logs do not preserve who performed the mapping mutation. This is follow-up hardening and does not change the NO_GO basis.