feat(tui): track sandbox creation as a per-target step

[raphaelvigee]

What

Adds a SandboxCreate step, tracked start→end and rendered as a per-target op in the TUI (flagged slow when it runs long), like any other step (execute, cache read/write).

It wraps the sandbox build — creating the dirs + materializing every declared input (unpack / hardlink-stage / FUSE-slot register) — which is the slow part on big inputs, a cold stage, or a FUSE mount (see #102). This is distinct from the Execute op, which covers only the subprocess run, so the TUI now shows why a target stalls.

How

• hcore::events — new SandboxCreate{Start,End} variants + a sender-based emit_scope_tx(Option<EventSender>, …). The engine's existing emit_scope needs RequestState; the driver bridge sits below the engine, so it gets a variant keyed on a raw EventSender. Drop-guard fires End on completion, ?, or cancellation.
• RunRequest.events: Option<EventSender> — plumbed from RequestState in execute.rs. None is a transparent no-op (tests, remote serve path).
• Driver bridge owns the create step, so it emits: both OS and FUSE run_inner wrap their materialization in the scope.
• TUI Op::SandboxCreate (icon ⊞), ordered between remote-read and execute.

Tests

• core: emit_scope_tx emits start+end on success, captures error in End, still emits End on cancellation.
• driver-bridge: run emits SandboxCreate Start+End carrying the target addr.
• tui: folds ahead of Execute in the breakdown; a long-running sandbox build surfaces on its own slow row with the right icon.

lint (full --all-targets clippy + fmt) and touched-crate tests green.

🤖 Generated with Claude Code