build: require Node >= 22 and build with Node 24

[antobinary]

What

Moves this plugin onto Node 24 and declares a supported-Node floor.

• package.json gains an engines field: "node": ">=22", mirrored into
  package-lock.json so the two agree.
• @types/node bumped to ^24.13.3 so the typings match the runtime the plugin
  is actually built with. It was declared twice, at ^20.3.1 and ^20.4.4;
  both are aligned here.
• CI moved from Node 20 to Node 24:
  • ts-code-compilation.yml — node-version: 20.x -> 24.x
  • ts-code-validation.yml — node-version: 20.x -> 24.x

This repo has no debian/ directory, no Debian package workflow, and no
publish-tag workflow, so there is nothing else to update. It is the smallest
Node 24 change of the fifteen.

Why >=22 and not >=24

The floor is the compatibility contract for anyone consuming or building the
plugin; 22 is still in maintenance and there is no reason to lock it out. The
preferred version is expressed where it takes effect — CI pins 24.

Testing

Against Node 24.20.0 / npm 11.19.0, running the same chain CI does:

• npm ci — PASS
• npx tsc — PASS
• npm run lint — PASS
• npm run build-bundle — PASS

Notes for review

The package-lock.json diff is confined to the engines block and the
@types/node resolution. lockfileVersion is unchanged.

[imdt-claudiop]

Approved.

Same shape as bigbluebutton/bbb-plugin-picture-in-picture#43, which is already merged: Node 24 across the workflows, nodejs (>= 22) in debian/control, and engines.node >= 22 plus @types/node ^24.13.3 in package.json.

Checked out this branch and ran it on Node 24.9.0:

• npm install clean, and package-lock.json shows no drift afterwards
• npx tsc passes (same command as the ts-code-compilation check)
• npm run lint passes (same command as the ts-code-validation check)
• npm run build-bundle produces dist/TourPlugin.js

I also scanned the rest of the tree for leftover references to the older Node line, and there are none.

Smaller diff than the sibling PRs in the other plugin repos, and that is correct: this repo has no debian/ directory and no deb or publish-tag workflows, so the two TypeScript workflows plus package.json are the whole surface.