Bind pagination cursors to their originating query

[deverman]

Closes #146

Acceptance journey

An opaque cursor continues the identical list query, including after output fields change. Reusing it after changing Review, status, search, dates, project, tags, completion, or another encoded filter fails before Bridge dispatch and tells the client to restart pagination.

Validation impact

query

Changes

• wrap Bridge offsets in versioned query-bound public cursor tokens
• validate and unwrap at the shared service boundary before Bridge dispatch
• apply separate cursor namespaces to tasks, projects, tags, and folders
• keep output fields outside the query key and preserve caller/default page limits
• document opaque cursor behavior in MCP schemas, CLI help, and query contract

Validation

• swift run focusrelay-dev validate --impact query — 168 tests and semantic gates passed
• direct MCP probes reject raw numeric and Review-to-non-Review cursor reuse
• unit coverage: valid continuation, malformed token, unsupported version, query mismatch, preserved limit, four tool namespaces
• live CLI pagination returned distinct page-two data for tasks, projects, tags, and folders; project/task/folder field changes remained valid
• live Review cursor reused without Review failed with Pagination cursor is for a different query. Restart pagination from the first page.