feat(deps): manually rebuild captured notebook environments

[rgbkrk]

This was generated by AI during triage.

Current triage (2026-07-10)

• Verdict: Keep open, narrowed to a user-requested rebuild of the already captured declaration.
• Current code: Captured dependencies are durable notebook state, but there is no clear manual rebuild surface with progress, cancellation, and outcome reporting.
• Next slice: Recreate the environment from the existing captured declaration without silently changing notebook dependencies or environment identity.
• Related: Refreshing the declaration from workspace defaults is now separate in feat(deps): refresh captured notebook dependencies from workspace defaults #3993; automatic infrastructure-failure repair remains fix(runtimed): rebuild captured environments after infrastructure launch failure #1969.

Priority: P3 (nice-to-have)
Related: #1954 (unified env resolution design)

Problem

Captured notebooks are fully self-describing but have no user-facing controls for the two common "I want to reset this" cases:

1. Rebuild env from scratch. Env got corrupted somehow, or user wants to pick up a newer package version. Today the user has to manually edit the .ipynb to clear metadata.runt.env_id and reopen. (If we ship auto-detect + recover in a companion issue, this becomes a manual escape hatch rather than the primary recovery path.)

2. Refresh deps from defaults. Daemon's default_packages setting changed (e.g. we added dx to the UV base set). Existing notebooks stay on their captured dep list by design (write-once, per issue design: unify env resolution so prewarmed notebooks maintain the same env across reopens #1954 § Capture timing). A user who wants to pick up the new defaults has no UI for it.

Design sketch

Both controls live in the deps header UI alongside the existing add/remove package actions.

Rebuild env:

• Button: "Rebuild environment."
• Confirm dialog: "This deletes the current environment and installs fresh from your captured deps. Continue?"
• Action: delete {cache}/{unified_hash}/, clear metadata.runt.env_id (so the next launch re-captures with a fresh env_id).

Refresh deps from defaults:

• Button: "Reset deps to workspace defaults."
• Confirm dialog: lists the current captured deps that will be removed and the new default deps that will replace them.
• Action: overwrite metadata.runt.{uv,conda}.dependencies with the current daemon.default_uv_packages() / daemon.default_conda_packages() (stripped of base), clear metadata.runt.env_id, next launch captures fresh.

Both share the "clear env_id, trigger fresh capture" mechanic. Worth factoring a single reset_notebook_env(strategy: RebuildSame | RefreshDefaults) call on the daemon.

Out of scope

• Automatic drift detection / prompt ("your defaults changed, want to refresh?"). Not needed yet; users who want this can hit the button.
• Env version pinning. Would be a separate feature.

Acceptance

• Deps header has both buttons, gated on the notebook being in a captured state.
• Rebuild deletes the current env dir and triggers fresh capture on next launch.
• Refresh-defaults overwrites captured deps with current workspace defaults and triggers fresh capture.
• Integration test: after Rebuild, unified_env_on_disk no longer hits at the pre-rebuild hash and a new launch recreates it.

[rgbkrk]

Triage refresh (2026-06-10, main at ed5131ec)

Both notebook-scoped controls are still absent. UvDependencyPanel.tsx, CondaDependencyPanel.tsx, and PixiDependencyPanel.tsx have no "Rebuild environment" or "Reset deps to workspace defaults" buttons. The only reset-adjacent action is the drift-triggered "Re-initialize" in the UV panel. No daemon-side reset_notebook_env() call exists either.

[rgbkrk]

Re-scoping the implementation sketch: the frontend-driven approach here (cache deletion, env_id rewrites) predates daemon-owned environment lifecycle. Rebuild and refresh-from-defaults should be daemon lifecycle APIs the frontend calls — the daemon owns captured envs, their states, and their rebuild machinery. The user-facing controls ask is unchanged; the mechanism moves behind the daemon API boundary.