feat: complete enterprise hardening and storage lock reliability

[ndycode]

Summary

• add enterprise hardening baseline (audit, ABAC, idempotency, retention, secret scan hooks, CI gates)
• harden secret key derivation and rotation command handling
• add file-based lock stale cleanup to prevent storage deadlocks
• add runbooks and operational docs

Validation

• npm test
• npm run lint
• npm run typecheck
• npm run build

note: greptile review for oc-chatgpt-multi-auth. cite files like lib/foo.ts:123. confirm regression tests + windows concurrency/token redaction coverage.

Greptile Summary

hardens account storage lock cleanup by detecting and removing stale locks from dead processes before acquisition. adds cleanupDeadProcessStorageLock that checks process liveness via process.kill(pid, 0) and removes locks from crashed processes or locks older than 120s.

key changes:

• new withStorageSerializedFileLock helper standardizes double-locking pattern (memory mutex -> file lock)
• lock acquisition order reversed from previous implementation (was file->memory, now memory->file)
• withAccountFileLock now runs cleanup before acquiring, wraps release in try-catch, and calls fallback cleanup
• releaseStorageLockFallback added for best-effort cleanup when normal release fails

concerns:

• no regression test added despite custom rule requirement (rule requires "reference the regression test added")
• missing observability: stale lock cleanup happens silently with no log entries (breaks ops runbook guidance at docs/runbooks/operations.md:74)
• lock order reversal is untested and could surface deadlock risks under contention
• process.kill(pid, 0) windows behavior not verified in tests

Confidence Score: 2/5

• addresses real production deadlock risk but lacks test coverage and observability for the new cleanup logic
• score reflects critical gap: custom rule 637a42e6 mandates "reference the regression test added" but pr has zero test changes. logic appears sound (pid-based dead process detection, timestamp-based staleness, best-effort fallback) but untested changes to concurrency primitives on windows desktop environments are high-risk. lock order reversal (file->memory to memory->file) needs validation. missing logging makes post-deployment debugging impossible.
• lib/storage.ts requires regression test coverage for cleanupDeadProcessStorageLock, especially windows process.kill(pid, 0) behavior and lock order reversal under contention

Important Files Changed

Filename	Overview
lib/storage.ts	added stale lock cleanup with pid-based dead process detection, reversed lock acquisition order (memory->file vs file->memory), missing regression tests for new cleanup logic

_{Last reviewed commit: 02d34d1}

Context used:

• Rule from dashboard - What: Every code change must explain how it defends against Windows filesystem concurrency bugs and ... (source)

[coderabbitai]

Warning

Rate limit exceeded

@ndycode has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 14 minutes and 26 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between d1c603e and 02d34d1.

📒 Files selected for processing (1)

• lib/storage.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/pr32-feedback

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

lock order reversed from previous implementation (was file->memory, now memory->file). old code: withAccountFileLock(() => withStorageLock(...)). verify no deadlock risk across all storage mutation paths.

Context Used: Rule from dashboard - What: Every code change must explain how it defends against Windows filesystem concurrency bugs and ... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: lib/storage.ts
Line: 122-124

Comment:
lock order reversed from previous implementation (was file->memory, now memory->file). old code: `withAccountFileLock(() => withStorageLock(...))`. verify no deadlock risk across all storage mutation paths.

**Context Used:** Rule from `dashboard` - What: Every code change must explain how it defends against Windows filesystem concurrency bugs and ... ([source](https://app.greptile.com/review/custom-context?memory=637a42e6-7a78-40d6-9ef8-6a45e02e73b6))

How can I resolve this? If you propose a fix, please make it concise.