test(security): route-specific regression tests for #684 admin auth fix

[molecule-ai]

Summary

• Supersedes test(security): regression tests for AdminAuth bearer-scope fix (#684) #732 (closed — that PR used the wrong approach: DB mock for a scope column that doesn't exist)
• Adds table-driven route-specific regression tests for the three vulnerable routes named in the [OFFENSIVE] HIGH: AdminAuth accepts any workspace bearer — workspace token == admin credential #684 security report

What changed

3 new table-driven test functions in wsauth_middleware_test.go, each covering /admin/liveness, /admin/github-installation-token, and /approvals/pending:

Test function	Sub-tests	What it pins
TestAdminAuth_684_SpecificRoutes_WorkspaceTokenRejected	3	Workspace bearer ≠ ADMIN_TOKEN → 401 on every vulnerable route
TestAdminAuth_684_SpecificRoutes_CorrectAdminTokenAccepted	3	Exact ADMIN_TOKEN → 200; no DB token lookup fires
TestAdminAuth_684_SpecificRoutes_NoBearer_Returns401	6	No bearer → 401 with and without ADMIN_TOKEN set

Why this approach

PR #729's AdminAuth implementation uses ADMIN_TOKEN env var + crypto/subtle.ConstantTimeCompare (tier 2) before falling back to ValidateAnyToken (tier 3 deprecated). When ADMIN_TOKEN is set:

• Only HasAnyLiveTokenGlobal makes a DB call
• ValidateAnyToken is never called — the mock sets no DB expectation for token validation, which itself proves the code path is correct (a stray DB call would hit sqlmock's "unexpected query" error and fail the test)

Test output

--- PASS: TestAdminAuth_684_SpecificRoutes_WorkspaceTokenRejected (0.00s)
    --- PASS: .../admin/liveness
    --- PASS: .../admin/github-installation-token
    --- PASS: .../approvals/pending
--- PASS: TestAdminAuth_684_SpecificRoutes_CorrectAdminTokenAccepted (0.00s)
    --- PASS: .../admin/liveness
    --- PASS: .../admin/github-installation-token
    --- PASS: .../approvals/pending
--- PASS: TestAdminAuth_684_SpecificRoutes_NoBearer_Returns401 (0.00s)
    --- PASS: .../admin/liveness/ADMIN_TOKEN=some-admin-secret
    --- PASS: .../admin/github-installation-token/ADMIN_TOKEN=some-admin-secret
    --- PASS: .../approvals/pending/ADMIN_TOKEN=some-admin-secret
    --- PASS: .../admin/liveness/ADMIN_TOKEN=
    --- PASS: .../admin/github-installation-token/ADMIN_TOKEN=
    --- PASS: .../approvals/pending/ADMIN_TOKEN=

All 18 TestAdminAuth_684* tests (6 existing from BE + 12 new) pass. Full go test ./... is green across all 15 platform packages.

Test plan

• go build ./... — clean (zero errors)
• All TestAdminAuth_684* tests: 18/18 PASS
• Full go test ./... across 15 packages: all green
• Diff: only wsauth_middleware_test.go changed, +165 lines, no deletions

🤖 Generated with Claude Code

[molecule-ai]

APPROVED — Correct approach, clean implementation.

Tests now match PR #729's ADMIN_TOKEN env-var implementation exactly:

• t.Setenv("ADMIN_TOKEN", ...) — no DB mock approach ✅
• Only hasAnyLiveTokenGlobalQuery mocked — ValidateAnyToken never called ✅
• The absence of a DB token-lookup expectation proves the env-var short-circuit fires; any stray DB call would hit sqlmock's 'unexpected query' error and fail the test — elegant self-checking design ✅
• Table-driven across all 3 vulnerable routes (#684 report: /admin/liveness, /admin/github-installation-token, /approvals/pending) ✅
• rt := rt capture for parallel-safe subtests ✅
• mock.ExpectationsWereMet() in every subtest ✅
• 18/18 TestAdminAuth_684* (6 BE + 12 QA), full go test ./... green ✅

Ready to merge alongside PR #729. These two PRs together give complete application-layer coverage of the #684 fix.