ci: give CodeQL real source to scan; make Ddraig the sole Pages deployer

[hyperpolymath]

Two of the five red checks on main, with two distinct root causes. Neither touches product code.

1. CodeQL — it was failing because it had nothing to scan

analyze (javascript-typescript) exited 32:

CodeQL detected code written in JavaScript/TypeScript but could not process any of it

statistikles is Julia + Agda + Zig. CodeQL supports none of those three, so the only analysable file in the repository is the ~100-line agent harness at .claude/workflows/prod-readiness.js (valid syntax — node --check passes). The JavaScript extractor skips dot-directories by default, so it extracted zero files and reported a configuration error.

This adds .github/codeql/codeql-config.yml naming that directory explicitly, wired in via config-file: on the init step. Existing SHA pins are untouched.

Honest scope — please read before trusting the badge. This covers the agent harness, not src/**/*.jl. A green CodeQL tick here means "the one JS file is clean" and says nothing about the statistical code. The real correctness gates remain e2e.yml (Julia suite) and agda.yml (agda --safe). The rationale is written into the config file header so the next reader doesn't have to rediscover it.

If you'd rather not carry a scanner that can't see the product code at all, deleting codeql.yml outright is the defensible alternative — say the word and I'll swap this half of the PR for that.

2. GitHub Pages — two deployers, both red

casket-pages.yml and pages.yml both declared concurrency: group: "pages", so they serialised rather than raced, and both failed:

• casket-pages.yml — died in ghcup, GHC 9.8.2 / cabal 3.10.3.0 not installed
• pages.yml (Ddraig) — HTTP 404, Pages not enabled on the repo

Ddraig is canonical (mass-deployed estate-wide in #56), so this removes casket-pages.yml. No site content is lost: casket built from site/, which does not exist here, and synthesised a placeholder index; Ddraig falls back to README.md the same way.

Verification

• Both YAML files parse (yaml.safe_load)
• Exactly one workflow with pages: write remains
• Commit signed (ED25519, %G? = G)
• Checked the ruleset first — the only required context is E2E — Julia Test Suite, so codeql is not a required check and this cannot wedge main
• Must be confirmed on this PR's CI run: CodeQL reports a non-zero extracted-file count. A pass with zero files is the same vacuous green in a new coat — the point of this change is that it stops being vacuous.

Correction to an earlier reading

error_count: 10 in the last Ddraig run is the deploy step's retry counter against the 404 — not ten build errors. The Ddraig build itself succeeded and uploaded its artifact. There is one root cause there, not eleven.

Not addressed here (owner actions / blocked)

• Enable GitHub Pages (Settings → Pages, source: GitHub Actions). Until then pages.yml 404s on every push to main.
• Rotate FARM_DISPATCH_TOKEN — Instant Sync fails Bad credentials; this is issue instant-sync: dispatch token invalid — red on every push #32. The workflow guards on token presence, not validity, so it cannot detect expiry.
• Governance red is blocked upstream, deliberately not fixed. CI instructs refreshing the standards reusable pins (d7c22711e830, 52 commits / 22d stale). Doing that makes the gitleaks gate real, which surfaces 23/23 false positives unless the .gitleaks.toml baseline lands first. Verified today: hyperpolymath/standards #512 is still OPEN and .gitleaks.toml 404s at standards root. Re-pinning now would be reverted.

Follow-ups spotted, not changed here

• pages.yml uses floating tags (actions/checkout@v4, upload-pages-artifact@v3) while the rest of this repo SHA-pins. It arrived via the estate mass-deploy, so fixing it here would create drift — better fixed at the source.
• e2e.yml's header claims "693 @test assertions, 10 Agda proofs". Measured: 841 and 3.

🤖 Generated with Claude Code

[hyperpolymath]

⚠️ Correction — the governance claim in the PR description is now stale

When I opened this PR I wrote that the Governance red was blocked upstream because hyperpolymath/standards #512 was still open and .gitleaks.toml 404'd at standards root. That was true when measured and is false now. Re-verified minutes later:

Fact	At PR open	Now
standards #512	OPEN, mergedAt: null	MERGED 2026-07-21T04:48:31Z
.gitleaks.toml at standards root	404	exists, 5372 bytes
standards main HEAD	f3b56e0b1e99	8813ecf2a841

The merge landed during this piece of work. The re-pin is therefore unblocked — refreshing this repo's stale d7c22711e830 reusable pins is now a real fix rather than something that would be reverted.

That is deliberately not folded into this PR — it is an unrelated concern with its own risk profile (making the gitleaks gate real) and belongs in its own change. Flagging it here so nobody reads the description above and concludes the work is still blocked.

The rest of the description stands: the CodeQL and Pages findings are unaffected.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud