Report the release version in released frontend builds

[kaysond]

Closes #998

What was happening

webapp/frontend/git.version.sh derives the version from GITHUB_REF_NAME / GITHUB_REF_TYPE when
CI is set. Two workflows call it, and they land on opposite sides of that check:

• docker-build.yaml runs on a tag push, so GITHUB_REF_TYPE=tag and the version is right.
• release.yaml is a workflow_dispatch on master, so GITHUB_REF_TYPE=branch and
  build_frontend writes master#<sha> into versions.ts.

The web UI shows that string, so every scrutiny-web-frontend.tar.gz attached to a release reports
the branch. That matches the report: v0.9.1, binaries.

Confirmed against what is actually published:

$ curl -sSL https://github.com/AnalogJ/scrutiny/releases/download/v0.9.1/scrutiny-web-frontend.tar.gz | tar -xz
$ grep -o 'appVersion="[^"]*"' dist/main.bf546340fdb53ee0.js
appVersion="master#d77976c"

$ docker run --rm --entrypoint sh ghcr.io/analogj/scrutiny:v0.9.1-web \
    -c 'grep -oh "appVersion=\"[^\"]*\"" /opt/scrutiny/web/*.js'
appVersion="v0.9.1"

So the docker images were already fine and only the binary/manual install path is wrong.

The fix

git.version.sh takes an explicit SCRUTINY_VERSION ahead of the existing logic, and release.yaml
passes the version that packagrio/action-bumpr-go has just written to version.go — which is the
authoritative version for that release, and is present in the workspace artifact the frontend job
downloads. The step fails the job rather than silently producing a bad string if it cannot read it.

Reading version.go avoids depending on the action's step output, which the workflow does not
currently consume anywhere and which would be empty if the action still used the retired
::set-output.

Verification

git.version.sh exercised in a container for every path:

scenario	env	writes
release	SCRUTINY_VERSION=v0.9.3, CI=true, ref master/branch	v0.9.3
tag push (docker images)	CI=true, GITHUB_REF_NAME=v0.9.3, GITHUB_REF_TYPE=tag	v0.9.3
branch push (nightly)	CI=true, GITHUB_REF_NAME=master, GITHUB_REF_TYPE=branch	master#abcdef1
empty override	SCRUTINY_VERSION=, tag push	v0.9.4 (falls through, no bare v)

And the workflow's extraction step:

input	result
the real version.go	ACCEPTED v0.9.2
file with no VERSION const	REJECTED
missing file	REJECTED
const VERSION = "1.10.0"	ACCEPTED v1.10.0

AI disclosure

Per AI_POLICY.md: this change was written by Claude Code (Opus 5). It diagnosed
the problem, confirmed it against the published v0.9.1 release asset and the published v0.9.1 docker
image, made the change, and ran the checks above in a container; nothing was installed on the host.

The one thing that cannot be exercised outside of GitHub Actions is the release workflow itself, so
the first real proof will be the next release.

That is the extent of the verification behind this PR as opened.