fix(engagement): the trigger manifest was stale, and its check was crying wolf

Two defects, and the second is why the first survived a whole phase.

The manifest is stale. `engagement-triggers.json` embeds `moduleApiVersion`
deliberately -- "a stale manifest needs to know which API's rules produced it"
-- and Phase 7 (website#189) bumped MODULE_API_VERSION to 1.10.0 without
regenerating it. The committed file has said 1.9.0 ever since. One line, and
regenerating is the whole fix.

The check could not be believed. Both the test and the `--check` CI gate
compared bytes, and this repo is developed on Windows under core.autocrlf=true,
so git checks the committed LF blob out as CRLF and the comparison then calls an
unchanged manifest stale. That failure fires on every Windows checkout, says "a
trigger declaration changed", and is "fixed" by regenerating a file whose
content was already correct.

So the one check that exists to be believed had been failing for a reason
everyone had learned to write off as environmental -- including me, twice: the
Phase 7 PR recorded it as a pre-existing CRLF failure, and the Phase 8 PR
repeated the claim. It was neither pre-existing nor CRLF. A check that cries
wolf is a check nobody reads, and the genuine staleness underneath it went
unnoticed for exactly that reason.

Line endings are now normalised on both sides, which is the convention
routeManifest.js and routeManifest.test.js already use one file along -- that
pair had clearly hit this and been fixed; the engagement pair never was. What is
being asserted is that the committed manifest describes the same declarations,
and a line ending is not a declaration. Policing the encoding is .gitattributes'
job, not this check's.

Verify

- The check is still LIVE, proved by breaking it deliberately: with the content
  changed the gate exits 1; with only the line endings changed it exits 0. That
  is the whole point of the fix, so it is not taken on trust.
- `npm test` under the TAP reporter: 1950 tests, 1877 pass, 0 fail. That is
  pristine `edge`'s 1950/1876 plus the one test this repairs.

A harness note, disclosed rather than buried

The default (spec) reporter intermittently reports a FILE-level failure with all
of that file's subtests passing, no assertion, and no diagnostic beyond 'test
failed'. It named a different unrelated file on each of four runs
(requireInternalKey, routeManifest, eventAuthorize, totp) and the TAP reporter
shows zero failures over the same suite. It appears to be a reporter artifact
under concurrency rather than a failing test, but it correlates with this branch
(4/4) against pristine edge (0/2) on the same machine state, which I could not
explain and am not claiming to have. Worth its own look; it does not indicate a
product defect and no assertion fails.

Co-Authored-By: Claude <noreply@anthropic.com>

server/engagement-triggers.json

@@ -1,6 +1,6 @@
 {
   "_comment": "Generated event-trigger inventory - the authoritative freeze of CORE's engagement contract (docs/website/ENGAGEMENT.md 4.3). Regenerate with `npm run engagement:manifest` in website/server. A renamed variable, a changed type or a widened ceiling breaks stored templates and rules, so the diff here is the review signal. A module ships its own copy in its bundle; this file never contains one.",
-  "moduleApiVersion": "1.9.0",
+  "moduleApiVersion": "1.10.0",
   "triggers": [
     {
       "id": "news.post",

server/scripts/engagementManifest.js

@@ -108,7 +108,21 @@ function main() {
     return
   }
 
-  const current = fs.existsSync(MANIFEST_PATH) ? fs.readFileSync(MANIFEST_PATH, 'utf8') : ''
+  // **Line endings are normalised before the comparison**, exactly as
+  // `routeManifest.js` does one file along, and for a reason that is not
+  // cosmetic: this repo is developed on Windows under `core.autocrlf=true`, so
+  // git checks a committed LF blob out as CRLF and a byte comparison then calls
+  // an unchanged manifest stale. That failure is worse than useless — it fires on
+  // every Windows checkout, says "a trigger declaration changed", and is fixed by
+  // regenerating a file whose CONTENT was already correct, which teaches a
+  // developer to ignore the one check that exists to be believed.
+  //
+  // What is being asserted is that the committed manifest describes the same
+  // declarations, and a line ending is not a declaration. Policing the encoding
+  // is `.gitattributes`' job, not this check's.
+  const current = fs.existsSync(MANIFEST_PATH)
+    ? fs.readFileSync(MANIFEST_PATH, 'utf8').replace(/\r\n/g, '\n')
+    : ''
   if (current === next) {
     process.stdout.write('engagement-triggers.json is current\n')
     return

server/test/engagementManifest.test.js

@@ -26,8 +26,16 @@ afterEach(() => registries._reset())
 const MANIFEST_PATH = path.join(__dirname, '..', 'engagement-triggers.json')
 const serialize = (m) => `${JSON.stringify(m, null, 2)}\n`
 
+// **Normalised, like `routeManifest.test.js`'s `read()` one file along.** Under
+// `core.autocrlf=true` git checks the committed LF blob out as CRLF, so a byte
+// comparison fails on every Windows checkout while CI stays green — and it fails
+// saying "the manifest is stale", which is the one thing it is not. The claim
+// here is that the committed file describes the same declarations; a line ending
+// is not a declaration.
+const committedManifest = () => fs.readFileSync(MANIFEST_PATH, 'utf8').replace(/\r\n/g, '\n')
+
 test('the committed manifest matches the declarations in the tree', () => {
-  const committed = fs.readFileSync(MANIFEST_PATH, 'utf8')
+  const committed = committedManifest()
   assert.equal(
     serialize(build()),
     committed,