fix(worktree): keep worktrees a thread or uncommitted work still uses

[Tryanks]

Closes #517
Refs #516

Changed behaviour

A fork keeps its source's cwd but deliberately carries no worktree ownership marker. So when the source thread went away, nothing counted the fork as a user of the source's worktree:

• Delete → remove worktree (Removing a deleted thread's worktree also deletes its forks' working directory #517). The delete dialog offered to remove the worktree, and the host ran git worktree remove --force on the directory the fork was working in.
• Startup orphan sweep (Startup orphan sweep force-removes worktrees the user chose to keep #516). A directory under ~/.tcode/worktrees/ whose name was not a loaded session id was force-removed. That covered a deleted source's worktree still used by its fork, and every worktree the user chose to keep on delete (Settings → Archived Threads → Delete always keeps). Uncommitted changes were lost; only the tcode/<id> branch survived.

What changes:

• SessionMeta::shares_worktree_with (core) is the one rule for "another thread works in this worktree": it owns the same branch, or its cwd lies inside the worktree directory. The delete dialog (worktree_orphaned_by_delete) and the host (delete_session) both use it. The host checks every stored session, archived ones included, plus live residents. So even when the client cannot see a sharer (an archived fork), the host keeps the directory and logs why.
• cleanup_orphans also receives every session's cwd and keeps any directory one of them lies in.
• The sweep no longer passes --force. Git refuses to remove a worktree with modified or untracked files, and that path already ends in the existing "leaving possible orphan" skip. So a worktree kept on delete never loses uncommitted work. Explicit removal (worktree::remove, used when the user picks "remove worktree") still forces.

#516 stays open: a clean worktree the user kept is still reclaimed by the sweep (nothing is lost; the branch survives). Honouring an explicit keep decision needs host-owned worktree ownership, which is #530.

Test

• orphan_cleanup_uses_age_and_ownership_and_leaves_unregistered_directories (services) is extended with two real git worktrees: one that a session's cwd lies in (a deleted source's fork) and one kept on delete with an untracked file. Both must survive an old-enough sweep. Checked red/green: restoring either the old id-only check or --force makes it fail.
• worktree_is_shared_by_a_fork_in_its_cwd_but_not_by_a_sibling_directory (core) pins the rule both callers depend on. A fork or a session in a subdirectory shares the worktree. A sibling directory with the same name prefix, the main checkout, the owner itself, and the fork's view of its source do not. Under the previous branch-only comparison the fork case fails.

There is no runtime-level test of delete_session itself: the removal runs on smol::unblock, so asserting that it didn't happen would need a timed wait. The decision it depends on is the core rule above.

Checks run locally (macOS)

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo nextest run --workspace --locked: 948 passed, 5 skipped

Not run locally: iOS/Android/Web checks and cargo machete (CI covers them).