Make the TLS pin checkout self-healing: skip needless fetches, re-clone on failure

[lann]

Fixes #32

Every CI run today fails in build-tls-component. Two problems compound:

1. GitHub's upload-pack serves fetch-by-sha only best-effort for
   non-tip commits, and polymorph-tls main moved past the pin this
   morning. Actions runners are refused consistently
   (upload-pack: not our ref 23ceddad…) while the same fetch succeeds
   elsewhere.
2. The checkout under target/deps/component-tls is restored from the
   rust-cache-managed target/ cache, and comes back with a mangled
   object store (fatal: unable to read tree, bad object refs/heads/main): refs claim history the store no longer holds. A
   branch fetch cannot heal that — negotiation believes the objects are
   already present — so no fetch strategy suffices.

The recipe now treats the checkout as disposable build territory:

• Skip fetching entirely when the pin's commit is already present
  (always true in a fresh clone, since the pin policy keeps revs
  reachable from upstream branches).
• Tolerate a refused fetch-by-sha.
• If checkout still cannot produce the pin, delete the directory,
  re-clone, and check out again. A branch clone involves no SHA wants,
  so it works on the refusing endpoints too.

Verified locally on all three paths: a fresh clone (no fetch), a stale
checkout parked on origin/main (checked back out without network),
and a corrupted store (deleted .git/objects/pack, refs intact) which
reproduced CI's failure signature and healed via the re-clone; the
component builds in each, and a second invocation is a no-op.

Unblocks #31, whose conformance job fails on this at build time.