[UX] Branch conversation without incompatible attachments

[Eastsidegunn]

Summary

Add a non-destructive model-switch escape hatch that creates a new conversation branch containing portable textual context while excluding incompatible native attachments from that branch's active provider projection.

This builds on the target-context projection introduced by #76. It must not mutate or delete the original branch, its messages, or its attachment registry.

Motivation

When every attachment in a conversation is incompatible with the requested model, merely suspending all files can make the remaining conversation misleading, while /new discards useful textual discussion. Users need a middle path:

Keep current model
Branch without files
Start a blank chat

Required semantics

• Fork from the current session position using Pi's existing branch/session machinery.
• Preserve portable text, tool history and summaries that remain meaningful without the native inputs.
• Establish an explicit compatibility boundary in the new branch.
• Exclude selected incompatible attachment/native-state identities from the new branch's active projection.
• Preserve the original branch unchanged and navigable.
• Never synthesize a file summary, conversion or placeholder claiming the target model saw the file.
• Make exclusions visible in branch metadata, /files, exports and SDK/RPC results.

UX

Offer Branch without files when a model-switch portability report finds all attachments incompatible, and optionally for partial incompatibility.

Before committing, show:

New branch for Azure OpenAI / gpt-5

Preserved
✓ conversation text
✓ results.xlsx

Excluded from this branch context
✗ demo.mp4 — video input unsupported

The user can confirm or cancel. Switching back to the original branch restores its original model/context state.

Non-goals

• Parsing or summarizing excluded files.
• Rewriting the original JSONL history.
• Automatic model routing.
• Replacing /new.
• Implementing the core projection engine tracked by [Portability] Apply confirmed lossy model switches to provider request context #76.

Acceptance criteria

• A branch can be created from a session containing incompatible native attachments.
• The original branch and attachment references are unchanged.
• The new branch preserves portable conversation context.
• Excluded attachments are not sent to the target provider.
• The compatibility boundary and excluded IDs survive save/resume.
• /files, JSON/HTML export and SDK/RPC inspection expose the branch exclusions.
• Returning to the original branch restores its prior attachment projection.
• No local conversion or fabricated file summary is introduced.
• Existing Pi branch/tree behavior remains compatible.

Dependency

Depends on #76.

[Eastsidegunn]

Scope review against the project charter

Hi-Fi Pi's charter is to leverage Pi's existing machinery as-is and open up native attachments. Judged against that, #76 is squarely in scope — attachment portability across providers is a problem this project created by opening native attachments, and making the confirmed-lossy contract actually work is completing our own feature. This issue is different: as written, it crosses from "attachment semantics on top of Pi" into "modifying Pi itself."

Running the issue item by item through that test:

Charter-compliant (leverages existing machinery):

• Forking at the current position works with Pi's existing entry tree as-is: a boundary marker appended as a child of the current leaf becomes the divergence point, and the original branch stays navigable via branch().
• The compatibility boundary fits the existing branch-scoped custom-entry mechanism (hifi.* pattern, survives resume, invisible to LLM context).
• Exclusion is just [Portability] Apply confirmed lossy model switches to provider request context #76's projection consulting one more entry type.

Charter-violating (modifies Pi surfaces unrelated to attachments):

• "Returning to the original branch restores its prior model/context state" is not how Pi works today — navigateTree() restores messages only; model/thinking/provider options are restored only at session resume. Implementing this changes the behavior of every /tree navigation, attachment-related or not. That is an upstream Pi feature, not a Hi-Fi Pi one.
• Tree-selector special-casing to display the boundary entry (custom entries are hidden by default) is a Pi UI modification.
• The dedicated three-option dialog and export-annotation surfaces extend Pi UX beyond the attachment layer.

For a fork/overlay project, each generic feature added here is permanent rebase surface against upstream.

Necessity is also weak once #76 lands

After #76, the all-attachments-incompatible scenario is already handled: suspend everything, keep the compact status indicator, continue the conversation; canonical history is preserved, and switching back to a compatible model re-activates the files. The additional value of Branch without files over that is largely aesthetic — not wanting to see suspended state — which doesn't justify modifying Pi's branch UX.

Disposition

Deferring/closing this issue (option 1) is the plan. Concretely:

• Park this until [Portability] Apply confirmed lossy model switches to provider request context #76 ships and real dogfooding shows the suspend-all model is insufficient. If that evidence appears, the fallback is a minimal rescope: existing /tree fork + a hifi.compatibility-boundary custom entry + [Portability] Apply confirmed lossy model switches to provider request context #76 projection consumption, with model restoration, tree-selector display, export annotation, and the dedicated dialog all explicitly out of scope.
• Per-branch model/context restoration on tree navigation should be extracted into an upstream Pi proposal regardless — it is a generic navigation improvement with no attachment dependency, and Hi-Fi Pi inherits it for free if upstream takes it.