Running on a `.json` file inserts a JS comment header and breaks the JSON

[Shinrai]

Problem

Pointing fix-headers at a .json file writes a /** … */ JS comment block at the top. JSON has no comments, so the file becomes invalid.

Reproduced on @cldmv/fix-headers@2.1.3:

npx fix-headers --input package.json --verbose
# fix-headers complete: scanned=1, updated=1, dryRun=false
# updated: package.json
head -3 package.json
# /**
#  *
#  *	@Project: fh-repro

Node then refuses the package. Every npm command in that directory, and any require() resolving through it, fails with:

Error: Invalid package config .../package.json.  code: 'ERR_INVALID_PACKAGE_CONFIG'

It happened for real during the CJS-entry sweep (CLDMV/vitest-runner#69): running it on package.json broke npm run build until the edit was reverted. The README lists JSON among the supported formats, so nothing warns you off doing this.

Fix

JSON (.json, .jsonc aside) can't carry a comment header. Skip strict-JSON files, or handle them explicitly in a way that keeps the file valid, and never write a comment into one. If --input names a file that is skipped, report it as skipped rather than "updated". Add a test asserting that package.json (and any *.json) is unchanged and still parses after a run.

[Shinrai]

Markdown has the same problem. A dry run of fix-headers --input <file>.md on a changelog file shows it would add a /** … */ JS comment block at the top. In Markdown that renders as visible text, and since the per-version changelog becomes the release PR body, it would also end up in the release notes. It was caught by the dry run during the 2026-10-03 release-docs sweep (CLDMV/uuid#53, CLDMV/droidsock#60), so nothing was written.

So the fix here should cover every format that can't carry a JS comment, not just JSON. Either skip the file, or use the format's own comment syntax (<!-- … --> for Markdown) if a header is actually wanted there. The test should cover .md as well as .json.

[cldmv-bot]

Marked status: implemented — resolved by #124, merged into next. This issue closes automatically when that work ships to the default branch.