test(ci): prove the cooldown rejects a freshly published release

[guyofeck]

Stacked on #597 — base that PR, not main. This is the test @dimar asked for in place of a code review:

i think the best "review" would be a test. Can we stack another PR on top of that and check if installing a fresh-package is rejected? I used npmjs.com/package/electron-nightly for always "fresh" versions

Adds cooldown-check.yml + check_cooldown.sh, which probes the real bunfig.toml setting in a temp project. Three cases, because an exit code alone can't tell a working guardrail from a broken probe:

Case	Must hold
control — bun add lodash	succeeds, so a red result means the cooldown fired, not that the probe broke
floating — bun add electron-nightly	refused, or resolves to a version ≥ 7 days old — asserted against the registry's publish time, so silently installing a 1-day-old version can't pass
exact pin — bun add electron-nightly@<newest>	refused. This is the bypass that matters: a PR pinning an exact fresh version

The cooldown is read out of bunfig.toml rather than hardcoded, so the test can't drift from the setting it verifies.

No gateway in this workflow, deliberately. Gatewayed, embargo would reject the fresh release itself and the run would prove nothing about Bun — which is the guardrail #597 relies on. check_wix_proxy_steps.py gains a third exemption and now records why each exists: the frozenset becomes a path -> reason dict, printed per exemption on success, so no exemption can be added without stating its justification.

No third-party actions, per the policy that landed with Actions being re-enabled: github_owned_allowed with empty patterns_allowed, and sha_pinning_required: true. So oven-sh/setup-bun isn't usable — Bun installs from a run step, and actions/checkout is pinned to 3d3c42e5 (v7.0.1).

Status

• bash -n clean; bunfig parsing smoke-tested (604800 → 7 days)
• check_wix_proxy_steps.py: 12/12 gatewayed jobs, all 3 exempt jobs verified to abstain; 13/13 unit tests
• Not yet run in CI — pushing this PR should trigger it via the pull_request path filter

Heads-up for @dimar

The rest of the repo can't run under the new policy yet: lint, test, typecheck, knip and both publish workflows all depend on oven-sh/setup-bun, which the empty patterns_allowed blocks, and 15 of 16 uses: refs are still tag-pinned. This workflow was written to need neither, so it can run today — but the others need either allowlist entries or the same curl-install treatment. Which do you prefer?

---

🤖 Generated with Claude Code

[guyofeck]

@dimar this is the test you asked for, and it passed on this PR.

Run: https://github.com/base44/cli/actions/runs/31491517277

Cooldown under test: 604800s (7 days)
Bun: 1.3.14

── control: bun add lodash ──────────────────────────────
PASS  control package installed, so the probe environment works

── floating: bun add electron-nightly ───────────────────────────────
PASS  resolved 45.0.0-nightly.20260803, published 679956s ago (>= cooldown)

── exact pin: bun add electron-nightly@<newest> ─────────────────────
Newest published: 45.0.0-nightly.20260810 (52760s old)
PASS  bun refused the exact fresh pin 45.0.0-nightly.20260810

RESULT: cooldown holds — fresh releases cannot enter the dependency tree

Reading the numbers: Bun skipped the Aug 10 nightly (52,760s ≈ 15 hours old) and resolved back to the Aug 3 one (679,956s ≈ 7.9 days). When pinned explicitly to the fresh version it refused outright — so both the floating resolve and the exact-pin bypass are closed. electron-nightly was your suggestion and it works well for this; it publishes nightly, so there is always something inside the window to reject.

The control case matters for trust in the result: bun add lodash succeeding proves a red run would mean the cooldown fired, not that the probe was broken. And the floating case asserts on the resolved version's publish time from the registry rather than on the exit code, so "silently installed something 15 hours old" cannot pass as green.

The run was ungatewayed on purpose — with embargo in front, the gateway would have rejected the fresh version itself and this would have proven nothing about Bun.

---

Separate problem this run surfaced. Every other workflow on this PR came back startup_failure:

Workflow	Result
Supply-chain Cooldown Check	✅ success
Package Preview Publish	❌ startup_failure
Check Wix Gateway Proxy	❌ startup_failure
Auto PR Description	❌ startup_failure
Claude Code Review	❌ startup_failure

The repo's policy is now github_owned_allowed: true, verified_allowed: false, patterns_allowed: [], plus sha_pinning_required: true. That blocks oven-sh/setup-bun, which lint, test, typecheck, knip and both publish workflows all need — and 15 of our 16 uses: refs are still tag-pinned. So the repo currently cannot run its own CI.

This workflow only ran because it was written to need neither: Bun installs from a run step and actions/checkout is SHA-pinned to 3d3c42e5 (v7.0.1).

Which would you prefer:

1. Allowlist the actions we need (oven-sh/setup-bun, denoland/setup-deno, and for the agent/publish workflows PostHog/upload-source-maps, peter-evans/repository-dispatch, anthropics/claude-code-action, lycheeverse/lychee-action), or
2. We drop third-party actions entirely and install toolchains via curl, the way this cooldown check does — more work up front, but then the allowlist never needs touching again.

Either way we'll do the SHA-pinning pass across all workflows; SHA-pinning alone won't help while patterns_allowed is empty.