Fail stale applying memory proposals

[caioribeiroclw-pixel]

Summary

• add a storage-level sweep for memory proposals stuck in applying after the apply grace window
• mark stale applies as failed with a stale_apply applied_result and audit event
• cover the memory and SQLite adapters plus service-level stale/applying behavior

Why

Issue #277 notes that a crash after approved -> applying can leave a visible applying row forever. This keeps that safe failure mode during the crash window, but lets the normal expiration cron surface old stuck applies as failed instead of requiring manual inspection.

Checks

• SKIP_DOCKER_SETUP=true pnpm test -- --runTestsByPath src/storage/adapters/__tests__/memory-proposals.spec.ts src/storage/adapters/__tests__/memory-proposals-sqlite.spec.ts ✅
• git diff --check ✅

I also tried the service spec path, but this checkout currently fails before running that suite because ../../proprietary/memory-proposals/memory-apply.dispatcher.ts cannot resolve @betterdb/agent-memory; leaving the service-level tests in this PR so CI with the normal workspace setup can exercise them.

Closes #277

[github-actions]

Thank you for your contribution! Before we can merge this PR, you need to sign our Contributor License Agreement.

To sign, please comment below with:

I have read the CLA Document and I hereby sign the CLA

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[KIvanow]

Thanks for the contribution! Clean fix for a real edge case — the stale-apply sweep is well-scoped, all three adapters are consistent, and the test coverage is solid. Appreciate you closing out #277.

@caioribeiroclw-pixel Before we can merge, you'll need to sign our CLA. Just post a comment on this PR with exactly:

I have read the CLA Document and I hereby sign the CLA

Details here: CLA Document

[KIvanow]

LGTM