Defensive enum hydration in recall read path (stale-MCP resilience)

From ops feedback #48 (root-caused, cycle 145). The flower MCP is served by long-running `mcp:start` processes that cache code at boot (like Horizon). When a new enum case lands (e.g. BriefOrigin::Feedback @ 90080cd, Jul 1), MCP servers that booted earlier hydrate it and HARD-CRASH with a BackedEnum/ValueError on recall_brief/recall_briefs for any brief using the new value. Recurring class: feedback #46, #48, and tool-visibility gaps #33/#36/#38/#39 — all stale cached code/registry. Fix: make the recall read path degrade gracefully instead of hard-failing on an unknown enum backing value — use tryFrom with an "unknown"/raw fallback (or catch ValueError and coerce) at model hydration / serialization for enums surfaced in read tools, so a stale reader returns the record (origin shown as raw/unknown) instead of erroring the whole tool. Scope: BriefOrigin at minimum; audit other enums in recall read paths (brief status, daemon role/status, harness type, etc.). This complements — does not replace — the MCP-reload discipline and #76 (self-reset); it fixes the class at the read layer so reader/writer code drift degrades rather than crashes. Tests: hydrate a record with an unknown enum backing value → the read tool returns gracefully (no exception). Full spec to follow at dispatch.