fix: clean repository staging after restore collisions

[yanpgwang]

Problem

A Git repository restore that lost a target-path race exited with code 73 after uploading and extracting its archive. The follow-up ownership check handled the target safely, but the sandbox-side .tar and .tree staging artifacts remained and could retain roughly two extra repository copies.

Solution

• remove the exact archive and extraction staging paths before resolving an exit-73 collision
• preserve the colliding target path for the ownership check and normal recovery behavior
• add a regression test that creates a target collision during restore and verifies both staging artifacts are gone
• update the stale SessionResource union comment to include Git repository snapshots

Acceptance criteria

• restore collisions leave neither the uploaded archive nor extracted staging tree
• collision targets are not modified by staging cleanup
• cleanup failures remain retryable instead of silently leaking data
• existing idempotent restore behavior remains unchanged

Durability and security

Cleanup is scoped to deterministic paths under Mango’s guarded repository staging root. It does not remove the user-visible target. No public API, persistence schema, credential handling, or network policy changes are included.

Tests

• make verify

Non-goals

Private repository authentication, repository Skill discovery, and new checkout modes remain separate product slices.