v2.5.1 — server-served operating context

Server-served operating context: CPersona can now carry the operating doctrine itself (project_id registry, agent_id conventions, recall discipline) instead of every client re-deriving it from local prose.

Added

• Operator-owned TOML sidecar (cpersona/operating_context.py) at ~/.cpersona/operating-context.toml, with a CPERSONA_OPERATING_CONTEXT_PATH override and a CPERSONA_OPERATING_CONTEXT=off kill switch. Lazy mtime-based reload. An absent or invalid file degrades to fully dormant — a config typo can never take memory down.
• Soft layer: instructions.summary rides the MCP initialize response through a new ToolRegistry(instructions=...) kwarg, so a connecting client receives the doctrine as part of the handshake.
• Hard layer: a boundary gate on the six project_id-accepting tools — registry validation (off / warn / reject) plus an opt-in @auto sentinel resolved from [defaults], echoed back as resolved_project_id. Reads warn even under reject (damage asymmetry: a bad read is recoverable, a misfiled write is not). Explicit values are never rewritten, omitted / "" semantics are untouched, and library callers bypass the gate by design.
• get_operating_context — a new read-only tool (28 → 29). The write path stays the filesystem: there is deliberately no MCP write tool for operator config.
• check_health: additive operating_context_parse (warn) and operating_context_size (info, 3,000-char budget) registry entries.

Contract

No DB schema change. No breaking change: the tool surface is additive (one new tool, additive response fields), consistent with the 2.5.x line declaration in SUPPORT.md. The feature is entirely dormant until an operator creates the sidecar.

Verification

430 passed / 5 skipped, ruff clean, issue registry 110 verified / 0 stale / 0 errors. Full CI green on master before tagging.

Design: docs/OPERATING_CONTEXT_DESIGN.md.