health/status should distinguish degraded health from actual API usability

[MatrixAdventurer]

Summary

A degraded health response is easy to interpret as "Memoria is unusable", even when actual client workflows such as search/store may still be functioning.

What I observed

In real OpenClaw + thememoria usage:

• health-style responses previously indicated degraded state
• but actual memory operations were still usable in practice
  • search/retrieval worked
  • memory writes worked
  • batch memory sync worked

This suggests there is an important distinction between:

• instance health degradation
• complete service outage
• reduced but usable service

Why this matters

Client/tool integrations often use health as a high-signal user-facing status.
If degraded health is surfaced without enough nuance, users may assume:

• memory is fully broken
• store/search is impossible
• setup/config is wrong on their side

when the real situation is closer to:

• service degraded
• but core APIs still usable

Expected

Health/status reporting should help clients distinguish between:

• total outage
• degraded but usable
• healthy

And ideally expose enough structure for client integrations to say things like:

• "health degraded, but read/store APIs still responding"
• "service reachable, database degraded"
• "writes may be impacted, reads still available"

Why now

This matters more as integrations begin using Memoria for real durable memory workflows rather than just smoke tests, because "degraded" and "unusable" are very different outcomes operationally.

[MatrixAdventurer]

Relationship note: this now reads as the generalized / longer-lived version of the earlier cloud-health incident tracked in #129. #129 was incident-specific; this issue is the broader product/status-model question about distinguishing degraded health from actual API usability.