Reduce release latency with concurrent gates and shared Go caches

[SaladDay]

Outcome

Release checks and distribution builds now run concurrently against the same source commit. Publication waits for both successful jobs. The complete make check gate and distribution verification remain unchanged.

Both jobs use the same Go module/compiler-cache directories and dependency/platform/source keys. Restored entries only seed Go's content-addressed work; every check still executes. This avoids restoring an unused cache and recompiling unchanged inputs in separate directories.

Scope and cost

Depends on #208, including its combined Runtime image correction and public latest/version bootstrap. No business behavior, tests, supported platforms, installation semantics or publication recovery behavior changes. Concurrent builds can consume runner time when checks later fail; successful-run runner costs and cache behavior are recorded below.

Validation

• Workflow lint and fresh independent full-diff review pass; no substantiated review findings. No tests or assertions were changed.
• Baseline complete candidate 36525478276 and optimized complete candidate 36525849316 both passed full make check, complete distribution build/verification and actual draft Release uploads.
• Both drafts contain 13 unique uploaded assets. The three checksum assets match GitHub's uploaded-file digests; their bootstrap matches the pinned source byte-for-byte.

Actual run	Check job	Build job	Release job	Workflow elapsed	Runner minutes
Baseline, existing caches	23m51s	11m03s	2m15s	37m19s	37.15
Concurrent, new caches missed	30m33s	12m31s	1m22s	32m02s	44.43
Concurrent, complete default-branch cache hit	25m09s	11m49s	1m58s	27m15s	38.93

Each job queued for 2 seconds; dependency waiting is not counted as queue time. The first optimized run reduced wall time by 5m17s (14.2%) despite cold caches, while consuming more runner time (19.6%). This is not a warm-to-warm cache comparison: the baseline restored its existing Go cache, while the new cache namespace was empty. The first concurrent build saved a partial compiler/module seed of about 365 MB before the check job could save its larger cache; this affects performance only. The warmed run restored the complete 797 MB default-branch cache in both jobs. Against the successful warm baseline, wall time fell 10m04s (27.0%), while runner consumption rose 1.78 minutes (4.8%). Cache restoration took 21–22 seconds per optimized job. These are individual GitHub-hosted runs, not controlled repeated samples; check duration and disk cleanup vary. The two revisions differ only in workflows, contributor/maintainer rules and unrelated README/banner/docs metadata; application and test sources are unchanged.

The maintainer requested delivery priority. PR #208 and this PR are merged, and authorized tag v0.0.1 points to 0f6191de261bb80d9dd0566ba6c86f9e9ac12de5. Its formal push workflow passed the complete checks/build and published v0.0.1. From workflow creation to publication took 32m14s (32m18s through final job cleanup), with new-cache misses. Performance comparisons do not gate delivery. The redundant PR-only check was canceled after merge; the complete candidate and formal tag gates passed.

The published Release has 13 uploaded assets, matching checksums and source-identical bootstrap; authenticated latest and explicit-version APIs resolve the same Release and source tag. The final-source offline artifact was downloaded through the remote network tunnel, its archive and contained package checksums verified, then installed on Linux amd64 as an ordinary user in a new isolated directory with --sandbox none. Core and Web /healthz both returned 200, and installation state matched the formal source commit. No existing environment or data was removed. Warm-cache full candidate measurement 36530077631 passed checks, build and actual draft publication using the frozen formal workflow/source. Its 13 assets and three checksum records passed the same receipt validation; the formal latest release remains v0.0.1. The validation branch prevents later main changes from affecting the comparison. GitHub currently marks the repository internal, so anonymous API access returns 404; no authentication logic was added to the public installer, and repository visibility was not changed.

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is disabled.}