docs: propose durable client-side retain outbox pattern

[Kosello]

Summary

This draft proposes a documented client-side durability pattern for Hermes Agent and other Hindsight integrations that must survive temporary Hindsight outages or client restarts.

It adds only:

• hindsight-integrations/hermes-durable-outbox/README.md

The document describes the contract and validation matrix for a profile-scoped SQLite retain outbox: persist before dispatch, atomic claims, bounded retry, stale-claim recovery, restart replay, stable operation IDs where supported, and explicit at-least-once limitations.

Scope boundary

This PR does not change Hindsight server code, schema, API semantics, extraction, embeddings, reranking, consolidation, recall, or reflect behavior. It does not register a released integration or alter the integration index; it is a reviewable proposal for maintainers to decide whether a common pattern or SDK guidance is useful.

Related work

• Hermes implementation proposal: feat(memory): durably buffer Hindsight retains across outages NousResearch/hermes-agent#95755
• Hermes existing retain-queue discussion: fix(hindsight): queue failed retain writes NousResearch/hermes-agent#54989
• Hindsight design issue: Proposal: document durable client-side retain buffering for offline integrations #3821

Questions for review

1. Should Hindsight document a recommended client-side outbox pattern for integrations?
2. What operation-ID/idempotency guarantees should the SDK document?
3. Should a reusable helper live under hindsight-integrations, or should each client own its queue?
4. What is the canonical interpretation of an operation-status 404 after retention?

This is intentionally a draft and contains no Hindsight server migration.