architecture(auth): migrate local credential authority behind released Keyverse contract

[seonghobae]

Gap

ScopeWeave currently implements password hashing/verification and JWT issuance locally in server/auth.mjs. That path is being repair-hardened in #674 because it is deployed behavior, but it is not the target bounded-context ownership: Keyverse is the canonical identity backend. ScopeWeave should own login/signup/recovery product forms and product-specific application/authorization composition, not duplicate credential and identity lifecycle truth.

This is a successor architecture lane, not a reason to delay the immediate #674 security repair.

Live owner prerequisite

Fresh Keyverse authority already contains the correct target direction in keyverse#128@f893ec6f5ecf1a324365b684505f8dff0cbc468c: products render their own login/signup/recovery forms while Keyverse verifies credentials and issues tokens. However #128 is open Draft, based on e6da5dd3762b45acf4e0a70b672327f38f4ba04b, and its own current body says the replacement ceremony is not implemented and no released API/runtime acceptance is claimed. ScopeWeave must therefore preserve this issue as a dependent consumer lane rather than bind to that mutable head.

Owner-path prerequisite for this issue: Keyverse #128 (or a verified successor) must reach protected integration and publish the immutable versioned ceremony/client/schema contract with its required security, real product-origin WebAuthn/authorization-code, recovery, provenance, and rollback evidence.

Constraints

• Consume only a released, immutable Keyverse API/client/schema. No mutable sibling PR-head dependency.
• No source copy of Keyverse credential/token/recovery policy and no cross-service SQL.
• Keep ScopeWeave WBS/project aggregate truth and Ubiquitous Language in ScopeWeave.
• Put Keyverse behind a ScopeWeave anti-corruption layer that maps identity outcomes into product application commands/results without leaking provider internals through the domain model.
• Login, signup, and recovery remain ScopeWeave product forms; identity truth remains Keyverse.
• Existing local credentials require an explicit migration/recovery strategy and rollback. Do not silently invalidate accounts.

RED evidence

Protected develop@2c328875e00e86537df3e965170be80532571cad contains local password/JWT authority in server/auth.mjs and /api/auth/*. #674 demonstrates why continuing to duplicate security-critical identity policy in the product creates independent repair and review burden.

GREEN acceptance

1. A canonical Keyverse release exists with versioned login/signup/recovery/session/token contract, immutable artifact, changelog, SBOM/provenance, reproducibility, and rollback evidence.
2. ScopeWeave pins that released contract/client through an ACL; exact-head API-schema/contract tests fail closed on incompatible versions.
3. Existing local credential accounts have a tested migration or explicit recovery path; rollback preserves account access and auditability.
4. Product forms cover normal/loading/error/permission/recovery states and retain product-specific UX while all credential/token lifecycle truth is delegated to Keyverse.
5. Tenant and product authorization composition remains explicit in ScopeWeave; Keyverse identity responses do not become cross-service SQL/domain leakage.
6. Current-head unit/API/E2E/security tests prove login/signup/recovery, revoked/expired session handling, permission errors, migration, and rollback.
7. Local credential/JWT authority is removed only after equivalence, migration, recovery, and rollback evidence are GREEN on one protected generation.
8. docs/product-technical-gap-baseline.md, architecture/ADR/security/operability/recovery docs are updated to code-current ownership and released contract version.

Dependency order

#674 immediate repair → Keyverse #128 owner implementation/protected integration/immutable release → ScopeWeave ACL/contract RED → migration/recovery implementation → exact-head GREEN → normal protected merge → local credential authority removal.