fix: unarchive keeps a thread active, kept worktrees survive the sweep, delete cascades to descendants

[Tryanks]

Phase 0 of #535, one commit per bug. Closes #515, #516, #518.

#515 — unarchiving a thread refreshes its activity time

unarchive_session stamps updated_at = now on the root and every cascade member it restores, so auto_archive_candidates no longer takes an idle thread straight back; a thread that had been read keeps last_visited ahead of the new updated_at so no false unread dot appears. The thread moves to the top of its list (accepted). Test: unarchive through the pipe, then AutoArchiveSweep acks ArchivedCount(0); fails before the fix.

#516 — the orphan sweep leaves worktrees the user kept

Correcting the issue: forks sharing a deleted source's cwd were already protected, and removal was never forced. The real gap was a clean worktree deleted with "Keep": nothing recorded the choice, so the sweep removed it after an hour. A kept_worktrees table (created on open if missing, no schema version change) records the directory in the same transaction as the delete, and the sweep skips it. A second cause found in the area: worktrees were always provisioned in and swept from ~/.tcode/worktrees regardless of the data dir, so a TCODE_DATA_DIR profile swept the default profile's worktrees; they now live in <data dir>/worktrees and each store sweeps its own (TCODE_WORKTREES_DIR removed; the default data dir is ~/.tcode, so nothing moves for default users). Test: a deleted-with-keep worktree and a fork's shared worktree survive the sweep while a genuine orphan is removed; fails before the fix.

#518 — deleting a thread deletes every thread under it

Delete cascades over the same descendant tree archive uses: every member's provider and background work is stopped, registrations closed, and all metas and event logs removed in one store transaction (StoreWrite::RemoveSessions). Worktrees follow the single remove_worktree flag; with it set, a worktree is removed only when no surviving thread works in it. descendant_session_ids moved to tcode-core (O(n)) and is shared by the runtime and the client's count. The confirmation dialog states the count when there are descendants; the client computes it from its index replica plus the archived list (Query::ArchivedSessions, which it already uses), because orchestrated children are usually auto-archived — no wire change. Sidebar delete and Settings → Archived → Delete now share one dialog. New string sidebar.delete_tree_description in both locales. Tests: delete a parent through the pipe, the parked grandchild's provider gets Shutdown, the reopened store holds only the unrelated thread; the client's count includes archived descendants.

Looked at in the app on a scratch data dir: light/dark, 1200 pt and 426 pt, en and zh-CN.

Delete all archived (fourth commit)

The confirmation now states the archived threads and the unarchived threads under them that the cascade takes (new strings in both locales when that count is non-zero), and the delete set is deduplicated: one DeleteSession per archived root, so a thread that is both archived and under another archived thread is neither counted nor deleted twice. Test: archived parent + unarchived child → (1, 1) and exactly one delete; archived parent + archived child → (2, 0) and exactly one delete; fails with dedup disabled. Looked at in the app in both themes and languages, wide and narrow.

Known edges, left as they are

• The worktree prompt is still root-only: if only descendants own worktrees there is no prompt, they are kept and recorded as kept.
• The kept list only grows (paths are per-session UUIDs, so stale rows are harmless).

Checks run

cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo nextest run --workspace --locked (949 passed, 11 skipped), cargo machete, Web and iOS checks, locale parity. Not run: Android, Windows, Linux.

• This change alters the wire protocol, so the next release needs a
  PROTOCOL_VERSION bump: a note was added under "Unreleased" above the
  constant in crates/protocol/src/lib.rs (the number itself changes only
  when the release is cut — CONTRIBUTING.md, principle 9).

[Tryanks]

Linux x64 failed store::tests::classifier_stop_and_review_preserve_diagnostics_until_the_next_turn (timeout). Settled at step 1 of the failing-test procedure: a driver fault that predates this branch. The test sent its live TurnStarted after waiting only for the status replica, i.e. possibly before the SessionEvents subscription was active, in which case the event is dropped (host-side it is emitted onto the bus, not logged; client-side live events are ignored until the events baseline) and the final wait can never succeed. Reproduced on main under CPU load (4/300), not at all after the fix (600/600). The driver now waits for baseline_ready(), as the app applies live events only after the baseline; no assertion or production code changed.