Builder: _ACTIVE_TELEMETRY is never cleared after a completed run, so an early exit in a later in-process main() call marks the PRIOR staging run failed

Surfaced by the sol round-3 review of PR #674 (evidence tier) as PLAUSIBLE, pre-existing on main since #563's main()→_main() wrapper.

Mechanics (tools/build_us_fiscal_refresh_release.py): _ACTIVE_TELEMETRY is a module global set/reset only inside _staging_telemetry(); telemetry.complete() does not clear it. The main() wrapper calls _ACTIVE_TELEMETRY.fail(error) on any BaseException. So in one Python process, after a completed staging-enabled run, a second main() invocation that exits BEFORE _staging_telemetry() runs — argparse SystemExit, the dirty-worktree SystemExit, _refuse_certified_release_dir_reuse, or (#674) a malformed --evidence-failure-owners file — rewrites/re-uploads the PRIOR run as failed.

Reachability: nil for one-process-per-CLI-run usage (every launcher today); real for any driver or test harness that invokes main() repeatedly in-process.

Minimal fix: clear _ACTIVE_TELEMETRY = None at main() entry (and in a finally after the failure report), keeping the current run referenced long enough for exception reporting; plus a consecutive-invocation regression test asserting an early-exit second call never mutates the first run's telemetry. Left to the #563 lane rather than folded into #674, which only adds one more early-exit site to a pre-existing set.

🤖 Generated with Claude Code

Start in tools/build_us_fiscal_refresh_release.py, following main(), _staging_telemetry(), and the _ACTIVE_TELEMETRY global. Reproduce two in-process main() calls where the second exits early, then add the consecutive-invocation regression test described in the issue. Done means the second call does not mutate or re-upload the first run's telemetry.