fix: harden credential storage foundation

[numnx]

Summary

Hardens the automation credential store as a reliable foundation for additional credential types. The audit found no plaintext-at-rest fallback, but it did identify consistency, authorization-race, global-ownership, key-initialization, input-validation, and dashboard-integration gaps.

Security and reliability changes

• Commit credential metadata and encrypted envelopes atomically for create, rotate/replace, and promotion.
• Use version/status compare-and-swap so only one overlapping value change can commit.
• Recheck project scope, status, capabilities, binding, and version after decryption; revocation and policy changes win against in-flight reads.
• Preserve an explicit management project for global credentials. Allowlisted projects may bind and resolve but cannot mutate another project's credential.
• Backfill legacy management ownership and remove global credentials if their management project is deleted.
• Validate runtime request shapes, identifiers, capabilities, list sizes, control characters, and a 64 KiB secret-size limit.
• Return explicit 400, 403, and 409 outcomes for validation, policy denial, and concurrent-write conflicts.
• Strictly validate mounted key files using one opened file descriptor, owner-only permissions, bounded size, and canonical 32-byte encodings.
• Serialize Electron key initialization within a process and atomically install one protected key across competing processes.
• Validate external Vault/KMS key material and expose the active key id/version in health results.
• Carry the credential broker through the runtime-to-dashboard dependency chain so credential health and management routes are actually available.
• Update canonical and public credential-security documentation.

Regression coverage

New adversarial coverage verifies:

• transaction rollback on initial, replacement, and promotion envelope failures;
• one-winner behavior for concurrent rotations;
• revocation during an in-flight resolve;
• global management-owner separation and owner deletion;
• malformed and oversized inputs;
• strict mounted-key parsing;
• Electron initialization races across one and multiple provider instances;
• external key identity/version validation;
• dashboard lifecycle and top-level server broker wiring;
• HTTP denial/conflict mappings.

Validation

• pnpm run ci
  • Quality guardrails passed
  • Dependency audit: no known high-severity vulnerabilities
  • Backend coverage: 5,464 passed, 7 skipped
  • Coverage: 83.85% lines, 83.81% functions, 72.35% branches, 82.61% statements
  • Dashboard: 2,149 passed, 2 skipped
  • Production build passed
• Live dashboard restart with automation security enabled:
  • /health returned UP
  • /ready returned 200 READY
  • /api/credentials/health returned structured provider metadata with 200

Risk and rollback

The database migration adds management ownership metadata and a cleanup trigger. Legacy global credentials select their first valid allowlisted project as manager; operators should verify that owner before expanding legacy allowlists. New write limits and strict array validation can reject previously malformed payloads instead of coercing them. Roll back this merge commit if credential management or migration behavior regresses; encrypted envelope formats remain unchanged.