compute: move MV sink persist I/O off Timely thread

[antiguru]

Convert the MV sink's mint, write, and append operators from AsyncOperatorBuilder to OperatorBuilderRc (sync) with dedicated Tokio tasks for persist I/O.
This removes async overhead from the Timely scheduling loop while keeping persist latency isolated from dataflow scheduling.

Key changes:

• mint: Tokio task watches persist upper via SyncActivator; operator manages capabilities and batch description minting
• write: Tokio task owns WriteHandle and CorrectionBuffer; operator sends commands via channel; ArcActivator coalesces redundant cross-thread activations
• append: Tokio task performs compare_and_append; operator forwards descriptions, batches, and frontier updates
• CorrectionLogger tracks net batch/record/size counts and retracts outstanding logging state on drop, fixing stale introspection rows after dataflow cancellation
• ChannelLogging bridges Correction events from Tokio task to Timely thread for introspection logging
• All tasks use abort_on_drop for prompt cleanup on dataflow shutdown

Shares the infra commit (compute/storage: add Send-safe infrastructure for sync Timely operators) with #35450.
Rebase before merging to deduplicate.

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[teskje]

The intention checks out to me. I'll note that for me this makes it noticeably harder to follow the logic and be sure that it's still correct, so we should only make this change if we have measured performance improvements. Aiui, the thinking is that Timely activations are expensive enough to justify the overhead of the additional tokio tasks and channels. It'd be great to have some numbers!

[antiguru]

bugbot run

[cursor]

PR Summary

Medium Risk
Reworks MV sink operators’ execution model and cross-thread coordination (Tokio tasks, channels, activators), which could affect sink correctness, progress, or shutdown behavior despite being largely a refactor.

Overview
Moves Materialized View sink persist interactions off Timely worker threads by refactoring the mint, write, and append operators to run persist I/O/state machines in spawned Tokio tasks, communicating with Timely via mpsc channels and SyncActivator-based wakeups.

Introduces StartSignal::into_send_future and tightens persist_source start-signal/listen hooks to be Send, plus updates correction buffering/logging to be task-safe via ChannelLogging/CorrectionLogger (including cleanup/retraction on async abort).

^{Written by Cursor Bugbot for commit 4ceac22. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.}

[frankmcsherry]

Aiui, the thinking is that Timely activations are expensive enough to justify the overhead of the additional tokio tasks and channels.

I think there's an additional issue that is maybe addressed that the async operators would not only schedule themselves often, but would also yield quite happily. I believe we figured this was the most likely candidate for "why Frank's catalog server became permanently wedged". The operators do need to be designed to handle overload gracefully, and not fall permanently behind.

It'd be great to have some numbers!

+1 on this. It may be that this is a recognized issue in a tracker somewhere, but if not definitely worth socializing what's up and why.