feat: Runtime API memory endpoints — bounded inspection and lifecycle controls

[Copilot]

The v0.9.4 Runtime API route table had no memory resource, leaving managed clients unable to inspect active memory, understand its scope/provenance, or apply lifecycle controls without a second memory store.

New endpoints (/v1/memory)

All routes are gated behind the existing require_runtime_token middleware.

Method	Path	Description
GET	/v1/memory	List entries; scope=global|workspace|all, q=<fts>, limit=1–200
GET	/v1/memory/{id}	Inspect one entry; scoped to global + current workspace origin
POST	/v1/memory	Append a new entry (scope: "global"|"workspace")
DELETE	/v1/memory	Clear all entries for a required scope= param

Example response shape:

{
  "entries": [{
    "id": 42,
    "scope": "global",
    "workspace_id": null,
    "summary": "prefer snake_case for identifiers",
    "stale": false,
    "line_start": 3,
    "line_end": 3,
    "status": "active"
  }],
  "total": 1
}

Redaction / safety

• Raw filesystem paths are never exposed; provenance is scope + workspace_id (SHA-256 digest of the git origin URL, not a local path)
• Summaries are bounded to 300 chars to prevent private-data exfiltration through the API surface
• GET /v1/memory/{id} applies the same get_for_workspace boundary as existing read surfaces — numeric IDs from another repo resolve to 404

Supporting changes

• NativeMemoryStore::list_all — new method for ordered full-scope listing without an FTS query (used when q= is absent)
• RuntimeCapabilities.memory: true — advertised in GET /v1/runtime/info; field is #[serde(default)] so older deserialization paths see false rather than an error
• Protocol crate test updated to cover the new field

• Fixes Runtime API: expose bounded memory inspection and lifecycle controls #5072

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
35663593	Triggered	Generic High Entropy Secret	23e2790	crates/tui/src/doctor/tests.rs	View secret
35663594	Triggered	Generic High Entropy Secret	23e2790	crates/tui/src/doctor/tests.rs	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[Hmbown]

Closing this stale draft as superseded. The bounded memory inspection and lifecycle surface landed on main in 548b8b52d.

I verified that the landed commit is contained in current main and that this draft has no substantive remaining feature scope beyond stale integration context. This draft should not be merged. Thank you for capturing the implementation intent.