Conversation sessions need a queryable product scope for project-bound transcripts

## Problem
WordPress Build can store product target metadata on chat sessions, but the generic conversation-session list path only filters by owner, agent, and context. A product cannot ask for "the latest chat session for project X" through the canonical session surface.

## Evidence
- `src/Transcripts/register-agents-conversation-session-abilities.php:201-204` accepts arbitrary `metadata` on create.
- `src/Transcripts/register-agents-conversation-session-abilities.php:595-598` documents metadata as JSON-serializable product-specific data.
- `src/Transcripts/class-wp-agent-cpt-conversation-store.php:236-256` lists sessions with owner/workspace plus optional `agent_slug` and `context` filters only.
- `src/Transcripts/class-wp-agent-cpt-conversation-store.php:151` and `src/Transcripts/class-wp-agent-cpt-conversation-store.php:225` persist metadata as opaque JSON, so nested product keys are not queryable by the generic list.

## Needed Primitive
Add a runtime-neutral way to scope/query conversation sessions, for example:

- a canonical `session_scope` / `thread_scope` string on session create/list; or
- a constrained metadata filter/index contract for namespaced product keys.

## Acceptance Criteria
- A caller can create a session scoped to an opaque product key like `wp-build-project:123` without Agents API knowing what that means.
- The list/bootstrap path can return sessions for that scope only.
- The shape remains product-neutral and works for non-WordPress-Build callers.

Downstream WP Build issue will link here; the product need is project-scoped transcripts so switching projects switches/restores the right chat.

Start with the create/list ability definitions in src/Transcripts/register-agents-conversation-session-abilities.php:201-204 and 595-598, then trace persistence and filtering in src/Transcripts/class-wp-agent-cpt-conversation-store.php:151 and 225-256. Define a product-neutral scope or constrained metadata contract, then verify that callers can create scoped sessions and that the list/bootstrap path returns only the requested scope.

Written by the indexing model from the issue text.