Add experimental sent-message editing

[ymichael]

Summary

• add a default-off editMessages experiment enforced by both the app and server
• let users edit any eligible completed message without changing history until submission
• reuse the queued-message inline editor styling; opening the editor focuses it without selecting its contents
• support Codex, Claude Code, and Pi through provider-native transcript checkpoints
• expose the atomic edit through the SDK and bb thread edit-message
• bump the host daemon protocol and include the implementation plan

Behavior

Opening or cancelling the inline editor is client-local and non-destructive. Submitting an edit stages provider history through the turn before the selected message, atomically replaces the selected conversation suffix, keeps workspace changes, and starts the edited turn.

Claude Code uses the latest assistant UUID with forkSession and upToMessageId. Pi records the session leaf entry and branches through it. Legacy Claude Code or Pi history without a checkpoint rejects safely when a retained turn is required.

Review hardening

• hash external operation IDs before deriving provider staging identities, preventing Pi path-sanitization collisions
• preserve and validate agent caller identity through the contract, CLI, edit service, persisted replacement turn, and permission policy
• recheck queued messages, pending interactions, and the editable event high-water mark in the atomic rewrite transaction
• keep the timeline edit handler stable so every cached row regains its action after an active turn becomes idle
• let connected realtime own history-rewrite refreshes, retaining mutation invalidation only as the disconnected fallback
• replace the thread-only search-segment index with (thread_id, source_seq) and add a generated migration plus exact query-plan coverage

Validation

• cross-package typechecks across the app, server, runtime, CLI, SDK, contracts, daemon, plugin SDK, templates, database, domain, and thread view
• full affected-package tests: 2,491 app tests, 1,400 server tests, and 857 agent-runtime tests, plus CLI, daemon, contracts, SDK, database, domain, and thread-view suites
• app lint and generated plugin SDK/template checks
• latest review-fix pass: 106 focused app/server/runtime/CLI tests, all 375 database tests, and 227 server-contract/SDK/plugin-SDK/template tests
• all 10 directly affected Turbo typecheck tasks pass; lint reports no errors
• credentialed standalone-dev-server QA passed through the source-built CLI for Codex, Claude Code, and Pi: editing an earlier message replaced the suffix, reran the edited turn, and preserved the replacement context on the next turn
• Pi QA confirmed the rewind session was adopted as the canonical provider session without leaving an operation-suffixed staging file

The Pi smoke pass used openai-codex/gpt-5.6-luna because the configured Anthropic route was out of extra usage.

Related to #1114

[SawyerHood]

🚨 SLOP COP 🚨 · review

I am the SlopCop. I am reviewing this pull request for security, code quality, performance, architecture, and end-to-end behavior.

[SawyerHood]

🚨 SLOP COP 🚨 · review

ELI5: This feature lets a user change an old message. BB removes later chat events and asks the provider to answer again.

I found three defects that must be fixed before merge.

• The edit waits for a host rewind without a shared thread lock. A send, queued message, or interaction can change state during that wait.
• The edit API removes the agent caller identity. An agent can edit another root thread and start the replacement with user permission policy.
• The API accepts any operation ID. Two different IDs can map to the same Pi session file and use the wrong checkpoint.

I also found six other defects.

• Each prepared rewind keeps a provider session and two runtime entries until the daemon restarts.
• The inline editor puts the caret at the end. It does not select the existing message.
• A completed new turn restores the edit action only on the latest message. A page reload restores actions on earlier messages.
• A connected client reloads history after realtime already reloads the same history.
• The search suffix delete has no (threadId, sourceSeq) index. It can scan a full long-thread search history under the write lock.
• The client does not check the active background-agent count. It can show an action that the server rejects.

The supported provider list also appears in the client, server, and runtime. A shared provider capability would reduce policy drift.

I tested the feature with the local app and a real Codex thread. A first-message edit worked, and an earlier edit removed the complete later suffix.

The final provider output was FINAL-REPLY. The removed secret and second turn were absent from the server timeline.

The five package type checks passed. The 68 focused app, server, and runtime tests passed.