Release tags and runtime version can drift #30

Problem

Release tags and GHCR images can advance while the runtime reports the stale version from package.json.

Observed on v5.4.1:

• main/tag commit: e23fe130673318e5dc2796db5d981405fff009cc
• both main and v5.4.1 GHCR workflows succeeded
• package.json and root package-lock.json still say 5.3.0
• GET / reads packageJson.version, so a container built from the v5.4.1 tag reports 5.3.0

This makes deployment verification ambiguous and allowed a release to look stale even when the correct image may be running.

Fix

Bump package.json and both root version fields in package-lock.json to 5.4.1 on an isolated branch. Going forward, the release flow must include a version-bump PR/commit before creating each v* tag, and CI should assert that a release tag vX.Y.Z matches the package version.

Acceptance criteria

• GET / reports 5.4.1 for a build from the corrected source
• package and lockfile root versions match
• release workflow fails when a v* tag and package version disagree
• image metadata exposes the source revision so operators can verify a running container independently of the display version