Let ci be run by hand

A question about the build cache should not need a commit to ask.

Every cargo invocation runs through sccache

cqx compiles a nine-crate workspace three times per push — natively, for wasm, and again for the conformance suite — and each of those started from nothing. The build cache now lives in R2, in the same shape deka and dsc use, so a push that changes one crate recompiles one crate.

One composite action rather than the same five environment variables in three jobs, which is three chances for them to stop agreeing. It installs sccache, proves the credentials reach that exact bucket, and exports RUSTC_WRAPPER so every cargo step after it is cached without anyone having to remember. Proving the bucket matters: sccache fails soft, so bad credentials would compile everything and write nothing, which looks like a slow build rather than a broken cache.

The jobs run in public-ci, whose token reaches the build caches and nothing else — not the release bucket, not the wasm bucket, not the product bucket. That is checked rather than assumed; r2-check reports it.

One departure from deka and dsc: a pull request from a fork gets a warning and an uncached build instead of a failure. GitHub withholds secrets from forks by design, and an outside contributor who cannot get a green check on a public repository is a worse outcome than a slow one.

The three sccache buckets this needed, plus cqx-releases and cqx-wasm, are created and scoped. linux-arm64 is deliberately not among them.

A way to ask what each environment can reach

The two environments hold their secrets under the same names with different tokens behind them, and neither the names nor the dashboard can show what a sealed secret is allowed to do. This asks R2 directly and prints reachability, never a credential.

Update README.md

Rename screenshot.png to screenshot-deno.png

Update README.md

Add files via upload

Merge pull request #40 from samifouad/claude/refresh-site

Ask cqx.bio to rebuild when a release lands

Ask cqx.bio to rebuild when a release lands

The site names the current release and links to the diff since the last one, and it reads that at build time because the front page is prerendered and should stay that way. So a release has to tell it.

Guarded on the secret rather than requiring it: cutting a release must not fail because a marketing site is not wired up yet.

Update README.md