fix(#931): stop the manifest test clobbering the tracked artifact, and retire a fossil

[TortoiseWolfe]

Closes #931.

Two defects, one file. The reported symptom — a permanently dirty working tree — was the smaller of them.

The test was silently discarding uncommitted work

generate-manifest.js resolved its output only against __dirname, so the test covering it could not run the generator without overwriting public/manifest.json. It compensated in a finally block:

git checkout -- public/manifest.json

That resets to HEAD, not to the pre-test working state. So running the suite threw away any uncommitted change to that file.

This was not deduced. It destroyed the fix below while that fix was in progress, and the second attempt is what exposed it. Anyone editing that file and running the suite loses the edit, with no error.

Fixed by making the generator honour MANIFEST_OUTPUT_DIR. The test now writes into its fixture and the destructive restore is gone.

The committed manifest was a fossil

detect-project.js:132 gives a non-empty base path only when isGitHubActions && info.isGitHub && !cnameExists. This repo has public/CNAME, so every build — local and deploy — produces '' and a start_url of /.

Production agrees:

	start_url
scripthammer.com/manifest.json	/
committed (before this PR)	/ScriptHammer/

A value the deploy has not produced since the custom domain was added, and which nothing serves. generated-manifest.test.js was pinning it, because defaultBasePath() returned /<projectName> unconditionally and ignored the CNAME clause.

Hence both symptoms from one stale expectation: every build rewrote the file, so the tree was never clean, and committing the correct regenerated value failed the test.

The committed manifest is regenerated to match reality, and it is idempotent — regenerating twice leaves no diff.

isGitHubActions is deliberately not replicated in the test. The committed artifact must represent what the deploy produces, and the deploy always runs in Actions; keying off the local environment would make the expectation flip depending on where the suite ran.

The fork protection is intact — that is the point of the test

Removing public/CNAME (a fork on github.io project pages) restores the /ScriptHammer expectation, so a DISABLE_BASE_PATH=true build committed there still fails.

without CNAME	2 pass / 1 fail
with CNAME	4 pass / 0 fail

New guard, mutation-tested

Added: the generator must honour MANIFEST_OUTPUT_DIR and must not touch the tracked artifact while doing it — the guard for the behaviour that made this file dangerous. Reverting the generator to its __dirname-only form fails two tests.

A correction, stated rather than quietly dropped

I originally filed #931 blaming the generators for both manifest.json and robots.txt. The robots half was wrong. Its committed value already matches production (https://scripthammer.com/sitemap.xml). It regenerated to the github.io fallback only in a worktree whose .env lacks NEXT_PUBLIC_DEPLOY_URL — a property of that worktree (#932), not of the generator. Nothing about robots.txt is changed here.

Verification

566/566  pnpm test:scripts
 exit 0  type-check
  clean  gitleaks
         a full suite run no longer modifies public/