feat(auth): add opt-in token issuance policy contracts

[pandemicsyn]

Summary

• Add Phase 1 shared token-policy infrastructure without changing production authentication, token issuance, or existing token validity.
• Separate resource-audience acceptance from credential-issuance eligibility, retaining validated audience, purpose, temporal claims, and explicit exchange eligibility in verified session/bearer contexts.
• Add canonical resource audiences while preserving operation-specific audience values, plus a single-audience payload builder that rejects reserved-claim overrides.
• Add policy and compatibility coverage and an issuer-to-consumer map documenting historical lifetimes, downstream token forwarding, and reader-first migration requirements.

Verification

• Manually reviewed the complete branch changes and confirmed existing web/Worker signers, authentication paths, and mandatory-audience checks are untouched.
• Corroborated the two historical five-year issuance durations against repository history and inspected concrete issuer/consumer paths documented in docs/token-issuance-policy.md.
• No manual endpoint or production-token testing was performed: this PR introduces opt-in helpers with no production callers. The findings are source analysis, not a runtime exploit reproduction.

Visual Changes

N/A

Reviewer Notes

• This is PR 1 of the planned two-PR sequence, not an enforced security fix. PR 2 will apply credential-issuance guards and endpoint regressions; reader/issuer migration remains separate.
• Review the strict distinction between missing legacy claims and explicit malformed, unknown, or mismatched restrictions. Existing operation-specific audiences must remain mandatory.
• The optional legacy exchange class accepts only original exp - iat values of 157680000 or 157788000 seconds, with a present pepper and no audience, modern restrictions, or system/scope markers. Unmarked five-year automation can still match this class; it is not proof of human provenance, and historical production populations remain unconfirmed.
• Modern exchange requires an explicitly exchangeable human API token whose sole audience is kilo-api. Marker rejection is deliberately conservative, including false or empty metadata values.
• Verified contexts must be passed by reference, and session adapters must use session-only verification. Signature verification and issuance eligibility do not replace account, environment, pepper, or revocation checks.
• No signing-secret rotation, token-version bump, global pepper reset, or mass invalidation is included.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (4 files)

• docs/token-issuance-policy.md
• packages/worker-utils/src/index.ts
• packages/worker-utils/src/kilo-token-policy.test.ts
• packages/worker-utils/src/kilo-token-policy.ts

Previous Review Summary (commit 15279b3)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 15279b3)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (6 files)

• docs/token-issuance-policy.md
• packages/worker-utils/package.json
• packages/worker-utils/src/index.ts
• packages/worker-utils/src/internal-service-token-audiences.ts
• packages/worker-utils/src/kilo-token-policy.test.ts
• packages/worker-utils/src/kilo-token-policy.ts

---

_{Reviewed by grok-4.6 · Input: 88.6K · Output: 13.4K · Cached: 287.4K}

_{Review guidance: REVIEW.md from base branch main}