Expose long-running synchronization through MCP Tasks

[pablontiv]

Description

Expose long-running Backscroll synchronization through the optional MCP Tasks extension. Instead of holding a tool request open while discovery, hashing, parsing, and indexing complete, the server can return a durable task handle that clients poll or observe until completion.

MCP Tasks supports durable taskId handles, status polling, progress visibility, reconnect-safe retrieval, mid-flight input, and cooperative cancellation:

• https://modelcontextprotocol.io/extensions/tasks/overview

Tasks provide the protocol lifecycle for long operations; they do not provide mutual exclusion or automatic deduplication.

Prerequisites

• Startup sync has quadratic session-text aggregation and can stall commands #46 defines the single-flight synchronization coordinator, lock behavior, and committed-snapshot read semantics.
• Expose Backscroll through a shared stateless MCP 2026-07-28 server #48 provides the reusable MCP 2026-07-28 server surface.

This issue must use those components rather than introduce another synchronization implementation.

Goals

• Return a durable MCP task when synchronization is expected to be long-running.
• Map Backscroll sync progress and terminal errors into MCP task status.
• Let disconnected clients resume polling with the same task ID within its TTL.
• Deduplicate concurrent sync requests through Startup sync has quadratic session-text aggregation and can stall commands #46's coordinator so callers observe the same active operation where appropriate.
• Keep search and other read operations available against the last committed snapshot while the task runs.
• Define cancellation semantics that preserve database atomicity and index integrity.

Proposed Task Lifecycle

1. A capable client calls the agreed sync operation.
2. The server durably creates a task before returning resultType: "task".
3. The task enters working while the Startup sync has quadratic session-text aggregation and can stall commands #46 coordinator owns synchronization.
4. Progress/status messages report bounded phases such as discovery, hashing, parsing, and commit.
5. tasks/get returns the current state and final result or error.
6. Terminal states are immutable: completed, failed, or cancelled.
7. Cooperative cancellation stops at a safe boundary and never exposes a partial transaction.

Non-goals

• Implementing the MCP server itself; tracked by Expose Backscroll through a shared stateless MCP 2026-07-28 server #48.
• Replacing Startup sync has quadratic session-text aggregation and can stall commands #46's cross-process coordination with task IDs.
• Moving ordinary search requests into background tasks.
• Guaranteeing Tasks support for clients that do not negotiate the extension.

Acceptance Criteria

• Tasks support is negotiated explicitly by both client and server.
• Long-running sync can return a durable task handle with documented TTL and polling interval.
• tasks/get exposes progress and a stable terminal result or structured error.
• Reconnecting clients can retrieve a non-expired task without depending on the original connection or conversation.
• Concurrent sync requests do not launch duplicate work and integrate with Startup sync has quadratic session-text aggregation and can stall commands #46's coordinator.
• Cancellation is cooperative, documented, and cannot leave a partial SQLite transaction visible.
• Clients without Tasks support receive a documented synchronous or unsupported-capability behavior.
• Integration tests cover polling, reconnect, deduplication, failure, expiry, and cancellation.