feat!: de-mavenize the build

[joewiz]

[This response was co-authored with Claude Code. -Joe]

Summary

Closes #180 by simplifying the release path. Modeled directly on monex@aa11953.

• Replace Maven with Node.js/Gulp; gulp now assembles the XAR end-to-end (.build/ → dist/exist-function-documentation-<version>.xar)
• Add expath-pkg.xml.tmpl / repo.xml.tmpl carrying the same dependency set as the prior xar-assembly.xml (exist 6.2.0 + html-templating 1.2.1) — no new runtime deps
• Move app metadata (target, namespace, title, etc.) into package.json#app
• Wire in semantic-release with conventional commits + commitlint
• New CI: build → install via @existdb/xst → cypress → semantic-release on master
• build.xml shim retained for downstream Ant callers

BREAKING CHANGE: builds now require Node.js (lts/*) instead of Maven.

Test plan

• npm ci && npm run build produces a valid XAR locally
• Generated expath-pkg.xml and repo.xml match the prior maven-templated output (same deps, same metadata)
• All 9 cypress specs pass against existdb/existdb:latest
• CI green
• After merge, semantic-release tags v2.2.0 and uploads the XAR to the GitHub release

[duncdrum]

@joewiz needs a rebase

[joewiz]

[This response was co-authored with Claude Code. -Joe]

Rebased and force-pushed (a9a59964). One conflict on package.json — master's dependabot bump to sass ^1.100.0 collided with the demavenize branch's sass ^1.99.0; took master's bumped version. Regenerated package-lock.json against the merged package.json so the lock is consistent.

[line-o]

I am in favour of pulling this PR in now.
One last thing might be that not all commits have been made using conventional commit message format. So the changelog might not include all changes yet.

[line-o]

Good news: there is only two commits that do not follow conventional commits format
Bad news: at least one of them is important to be included into the change log 566024e

[joewiz]

[This response was co-authored with Claude Code. -Joe]

Thanks for the approval! On the conventional-commits / changelog gap you flagged: the only commit on this branch is the single feat!: de-mavenize the build, which is conventional and will trigger a major bump → v3.0.0. The non-conventional commits sit on master already (566024e [fix] Rewrite search queries... from #178; 87672ed Update src/main/xar-resources/data/docs/util/index-keys_5.md; b618192 [maven-release-plugin] prepare for next development iteration) and we don't want to rewrite shared history to fix them.

Pushed dafb0ef to handle this without history rewriting:

1. Pre-populated <change version="3.0.0"> in repo.xml.tmpl covering [fix] Rewrite search queries to avoid parenthesised-step slow path #178 (the search-perf fix that wouldn't otherwise survive into the changelog). fix(documentation): add ngram-index to the list of indexes #152's docs fix is already covered by its sibling conventional commit 003fdd2 fix(documentation): ...; the maven-release-plugin commit is release-tooling noise we don't want in the changelog anyway.

2. Made scripts/update-repo-changelog.js merge-aware: if a <change> for the next version already exists in the template (i.e. someone hand-authored an entry to capture non-conventional commits), the script now prepends the auto-generated items into its existing <ul> instead of inserting a duplicate <change> block above it. Existing inline markup (<a href="...">#NNN</a>) is preserved.

Net effect: when v3.0.0 cuts, the in-app changelog will contain the auto-generated items from the feat! commit plus the pre-populated #178 entry — in one block, in that order. No interference with the release version computation (still driven by commit-analyzer) or the GitHub release notes (still driven by release-notes-generator) — repo.xml.tmpl is purely for the in-app changelog view.

[github-actions]

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

• v3.0.0
• GitHub release

Your semantic-release bot 📦🚀