release-notes: the post-clone scrub leaves the workload unable to fetch a private repo — silently

[debuggingfuture]

Post-clone, packages/runtime-cf/src/sandbox-cf.ts rewrites remote.origin.url to its credential-free form so the installation token does not outlive the clone (ADR-0006). Correct — but it leaves the workload with a remote it cannot fetch from on a private repo.

runs/release-notes.ts is the live case:

git fetch --tags --force origin >/dev/null 2>&1 || true
last=$(git describe --tags --abbrev=0 2>/dev/null || true)
if [ -n "$last" ]; then range="$last..HEAD"; else range="HEAD"; fi

On a private repo the fetch now 404s. It is || true, so nothing fails — last comes back empty, range falls back to HEAD, and the run emits notes over all history instead of since the last tag. A wrong answer, reported green.

Before #90 the container path had no scrub at all, so a webhook-mode run kept a working authenticated remote and this fetch succeeded. The scrub is right; the gap is that no workload-facing credential replaced it.

Currently latent: this repo has no tags, so git describe returns empty either way. It bites the first private repo with tags that runs release-notes.

Options:

• A short-lived credential helper scoped to the run, granted only to workloads that declare they need network git.
• Fetch what the run needs before the scrub, in the clone step, and hand the workload a tree that already has it (tags, in this case).
• Keep the scrub absolute and make the affected runs fail loudly rather than degrade — drop the || true so a fetch that cannot authenticate is an error, not silent history.

Raised by review on #90.