fix(ci): remove duplicate continue-on-error that made js-ci.yml unloadable

[felixgeelhaar]

Urgent — this is a regression I introduced in #49, and it is breaking every repo on js-ci.yml right now.

#49 added continue-on-error: true to js-ci's SARIF upload step. That step already had one. GitHub rejects the entire file:

klarlabs-studio/.github/.github/workflows/js-ci.yml@main
: (Line: 176, Col: 9): 'continue-on-error' is already defined

Why it was invisible

A workflow that fails to load produces no jobs, no logs, and no check contexts — just a bare failure with nothing to inspect. gh run view --log returns "log not found". I only found it because pet-medical-www#24 showed Warden provenance as its sole check while the CI run sat at failure, and dispatching the workflow manually printed the parse error that the PR run never surfaced.

Two failures in my own process

1. The guard was too narrow. My fix(ci): make the code-scanning SARIF upload best-effort (regression from #47) #49 script asserted no existing continue-on-error within 400 characters after the step name. js-ci's sits behind a longer comment block, so the assertion passed on a file that already had it. js-ci had already been fixed for this — with a comment saying the same thing — and only go-ci needed the change.
2. The YAML validation could not have caught it. PyYAML accepts duplicate mapping keys silently, last one wins, so yaml.safe_load reported the file as valid. GitHub does not. Validation now uses a loader that rejects duplicates:

go-ci.yml: OK (no duplicate keys)
js-ci.yml: OK (no duplicate keys)
nox-remediate.yml: OK (no duplicate keys)

go-ci's three continue-on-error occurrences are in three distinct steps — confirmed by the same strict loader, not by eye.

Fix

Remove the block #49 added to js-ci, keeping the original. go-ci is untouched and correct.

[felixgeelhaar]

Merged. Blast radius, checked across the three repos that call js-ci.yml:

Repo	Runs during the broken window (#49 → #50, ~35 min)
armada	none
fortify-ts	none
pet-medical-www	1 — my own PR (#24), which is how this was found

So nothing of anyone else's was affected. That is luck rather than good process: had any JS repo opened a PR in that window it would have hit a bare failure with no jobs, no logs and no check contexts, which is close to undiagnosable without knowing to dispatch the workflow manually to see the parse error.

The lasting fix is the validation, not the revert. yaml.safe_load reported the broken file as valid because PyYAML takes the last of duplicate keys silently — so the check I ran to prove #49 was safe could never have failed. Any future edit to these workflows should go through a loader that rejects duplicate mapping keys, which is what GitHub's parser does.