menu.ps1: hub-cache cleanup marker does not identify which session fetched it #1093

Found during PR #1091's review (CodeRabbit).

Invoke-Cleanup in host-setup/menu.ps1 deletes the shared --Dir hub cache
directory when the current process's own $script:HUB_FETCHED is true and the
hub.owned marker file still exists. Both signals are coarse: $HUB_FETCHED
is process-local (true only for the session that itself called
Invoke-FetchHub), but hub.owned is a shared, on-disk marker with no session
identity recorded in it.

If session A performs its own fetch, then session B starts (also pointed at
the same --Dir) and, before B's own cleanup runs, A's cleanup fires: A's
$HUB_FETCHED is true (A really did fetch) and the marker still exists, so A
proceeds to remove the shared hub directory — even if B is a -Keep session
relying on that checkout persisting, or is still actively reading it (the
Invoke-WithHubLock mutex prevents a torn removal mid-read, but does not
prevent a correctly serialized removal of a directory another live session
still wants kept). B's next action then silently re-fetches, or fails if it
never expected to.

menu.sh's equivalent flow does not have exactly this shape, since it has no
analogous per-fetch session marker at all — its own reader/writer flock is
scoped to the read/use span rather than to fetch identity, so this is a
PowerShell-specific design gap.

Suggested fix (CodeRabbit's proposal, not yet implemented): have each
fetch record a unique per-fetch token in the marker (or a sibling file), and
have Invoke-Cleanup compare that token against the one its own fetch wrote
before deleting, while holding the mutex, removing only on a match.

Deferred out of PR #1091 as a heavier design lift than that PR's own scope
(closing concrete rule-6 bypasses); tracked here for a follow-up pass.