Conversation sessions: actionable no-store error + record #235 decision

[lezama]

Summary

Small canonical-side change for #235. Two parts, only one touches behavior:

1. Actionable no-store error. When no host store is registered, the conversation session abilities now point at the `wordpress/agents-api-default-stores` companion (zero-config WordPress-native store) in addition to the `wp_agent_conversation_store` filter — turning a dead-end into a one-command fix. Error code (`agents_conversation_session_no_store`) is unchanged.
2. Decision record. `docs/default-stores-companion.md` now records the Consider a WordPress-native default conversation session store #235 resolution: the default conversation store lives in the companion package, not canonical.

Why companion, not canonical (the #235 decision)

• Canonical is on the WP-core landing path (Convergence audit: merge parallel WordPress agents-api extractions #77). A default CPT session store in canonical becomes a session post type core ships to every site — a likely core-review blocker and a migration liability. The companion never carries that.
• The posts-table-bloat concern (Data Machine's large post volumes) only bites consumers that don't override `wp_agent_conversation_store`. High-volume adopters override; the remaining audience is low-volume experiments for which a CPT is fine.
• The reference implementation already exists in openclawp (CPT + postmeta + lock). The companion store is an extraction + generalization, not new design — with added `WP_Agent_Principal_Conversation_Store` support (openclawp is user-keyed only).

The companion package itself is built separately (it requires `wordpress/agents-api` and is core-landing-neutral). This PR is just canonical's contribution to the cold-start experience.

Test plan

• `composer test` — full suite green. No test asserts on the error message text (the no-store path is covered by error code, unchanged), so no test updates needed.

Part of #235.