ci: add release automation and CodeQL

[mschmicking]

Ports the release workflow set from iobroker-sync, adapted for a native addon.

What this adds

File	Purpose
release-please.yml	Keeps an open chore(master): release x.y.z PR that accumulates merged changes, derives the version from conventional commits and rewrites CHANGELOG.md
release.yml	Publishes to npm when a GitHub Release is published, via trusted publishing (OIDC)
pr-title.yml	Validates PR titles, which release-please reads to work out the next version
codeql.yml	Static analysis of c-cpp and javascript
release-please-config.json / .release-please-manifest.json	release-please configuration, bootstrapped at 2.0.0
CHANGELOG.md	Written by hand for 2.0.0; release-please owns it from 2.0.1

Nothing publishes on an ordinary merge to master. Merging the release PR is the single deliberate act that ships a version.

Adaptations from iobroker-sync

• Branch is master, not main — release-please triggers on master, and master is in the allowed scope list because release-please titles its own PR chore(master): release …. Without that the release PR fails its own title check and becomes unmergeable.
• No typecheck/lint/format steps — there is no TypeScript or linter here.
• npm ci also compiles the addon, since the install script runs node-gyp. Ubuntu is unaffected by the Visual Studio detection problem that forces ci.yml to pin its own node-gyp on Windows.
• CodeQL is more valuable here. src/ is C++ driving a raw C API with hand-managed stack indices, string buffers and object lifetimes. The c-cpp run uses build-mode: manual and compiles the addon so CodeQL can observe it. Path filters are not honoured for compiled languages, so alerts will appear in vendor/ — dismiss those as won't-fix, since Lua 5.1.5 and LuaFileSystem are vendored verbatim and not patched here.
• Scope vocabulary retuned: lua, napi, build, vendor, lfs, deps, docs, release, master.

The tarball guard

The most important step in release.yml. This package builds from source on the user's machine, so a tarball missing the vendored Lua sources is unbuildable for everyone who installs it — and npm versions are immutable, so the only fix is a new version. The guard asserts all 29 Lua translation units are present, that the binding sources and licences are there, and that build/ and node_modules/ are not.

It reads npm pack --json, whose output shape changed between npm versions: npm 11 and earlier emit an array, npm 12 an object keyed by package name. I found this by running the script rather than trusting it — the naive require('./pack.json')[0].files throws on npm 12. It now accepts either shape and fails loudly if it can read neither, so an npm upgrade cannot turn the guard into a crash or, worse, a silent pass.

Verified locally against real npm pack output, a synthesised array-shaped payload, and a negative case with the vendored sources stripped (correctly rejected).

Heads-up for iobroker-sync: its ci.yml has the same require('./pack.json')[0].files assumption and will break when that repo moves to npm 12. Not touched here.

Also

• ci.yml aligned on actions/checkout@v7 / actions/setup-node@v7 to match. All pinned action versions were verified to exist.
• prepublishOnly: npm test so a manual publish cannot skip the tests.
• README gains a Releasing section.

Before the first release can run

Three things only you can do, in order:

1. npm owner add mschmicking node-lua-runner while logged in as 0x7878 — the package is currently owned by that account.
2. npm owner rm 0x7878 node-lua-runner from mschmicking, once the add is confirmed.
3. Configure the trusted publisher on npmjs.com for node-lua-runner: repository mschmicking/node-lua-runner, workflow release.yml. Without this the OIDC publish is rejected — there is no token fallback by design.

🤖 Generated with Claude Code

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.