feat(web): display app version in the sidebar, sourced from version.txt

[mforce]

Closes #458.

Problem

No visible version identifier anywhere in the app — no way to say "which build am I on" from a screenshot or support conversation.

A latent bug found along the way

web/src/api/errorReport.ts has always read import.meta.env.VITE_APP_VERSION for crash reports (the comment there says "set at build time... absent in dev builds"), but nothing ever actually set it — not in CI's npm run build, not in the Dockerfile's RUN npm run build. So every crash report, including from production, has been silently sending appVersion: undefined. Fixed as part of this change, not separately, since the fix is the same plumbing.

Design

Per discussion: extend release-please rather than invent new CI plumbing.

• web/.env.production (new) carries VITE_APP_VERSION=0.0.2. Vite loads .env.production automatically for a production-mode build (vite build defaults to mode: production) — no Dockerfile/CI changes needed beyond the file existing; COPY web/ ./ in the Dockerfile already picks it up, and it isn't excluded by .dockerignore (**/.env matches only the exact filename .env).
• .gitignore negates it (!web/.env.production) — the root .gitignore's .env.* pattern would otherwise block committing it. VITE_APP_VERSION is a public string baked into the client bundle regardless of whether it's committed, not a secret.
• release-please-config.json gains an extra-files entry using release-please's generic updater, anchored by an x-release-please-version marker comment on the line above the value (not a trailing same-line comment — dotenv-style .env parsing doesn't strip inline # comments the way YAML/generic key:value formats do, so a trailing marker would have become part of the value). This makes future release PRs bump web/.env.production in lockstep with version.txt/the manifest, same PR, same commit.
• AppLayout.tsx renders v{{version}} in the sidebar footer, next to the theme toggle/sign-out — the existing .sidebar-foot chrome. Absent entirely when the var is unset (dev/test builds), rather than rendering something broken.

Verification

• npm run typecheck / npm run i18n:scan (COUNT: 3, unchanged baseline) / npm test (1412/1412, +1 new) all green.
• Verified end-to-end with a real npm run build, not just the unit test: grepped the built bundle and confirmed 0.0.2 is correctly baked into both errorReport.ts's appVersion and AppLayout.tsx's APP_VERSION — proves the whole .env.production → Vite substitution pipeline actually works, not just that the code compiles.
• New test mutation-checked properly, including catching my own first mistake: I initially wrote the "no version shown when unset" test assuming i18next would render a missing {{version}} interpolation as "vundefined" (JS string-concat style) — wrong. Printed the actual DOM and found i18next renders it as a bare "v" (empty interpolation). Rewrote the test against the real behavior, then mutation-tested it (temporarily removed the APP_VERSION && guard) and confirmed it now correctly goes red.

What's unverified

I could not test the release-please-config.json extra-files wiring against a real release-please dry run (no network access to invoke the action here). This is the one part of the change that needs confirming on the next actual release PR — that web/.env.production's version line moves in lockstep with version.txt. If it doesn't, the marker-comment placement is the first thing to check.

Docs

Added a short note to docs/decisions/351-releases.md documenting the extra-files addition and why the marker comment is placed where it is (dotenv inline-comment gotcha).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d1a52a66e0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[mforce]

@codex address that feedback

[chatgpt-codex-connector]

Summary

• The review feedback was already addressed in commit a096192: the production Vite version is 0.0.3, matching both version.txt and the release-please manifest. web/.env.productionL1-L2 version.txtL1 .release-please-manifest.jsonL1-L3
• No additional changes or PR were created because the requested fix is already committed on the current PR branch and the working tree is clean.

Testing

• ✅ cd web && npm run typecheck
• ✅ cd web && npm run build
• ✅ cd web && rg -q '0\.0\.3' dist
• ✅ git status --porcelain (clean working tree)

View task →

[mforce]

Reopening: the extra-files sync this issue shipped didn't actually fire on the first real release (#461, v0.0.4). Root cause: release-please's generic updater matches a semver pattern only on the same line as the x-release-please-version marker — this PR put the marker on the line above the value, so it silently never matched. Filing the fix as a follow-up PR.