chore(ci): declare sonar.projectVersion so the new-code period means something (#79)

The quality gate has been grading the entire codebase rather than what changed. The server's new-code period is PREVIOUS_VERSION, but sonar.projectVersion was never set anywhere — not here, not in the workflow — so every analysis recorded "not provided" and there was no previous version to diff against. SonarQube's fallback is to treat everything as new.

The tell was visible in the measures all along: new_lines read 9460 against a total ncloc of 5496, and new_coverage tracked overall coverage to within two points. Both are what you would expect if "new code" meant "all code", and neither is surprising enough to notice unless you go looking. This is the fourth time the project has hit the same shape — a tool reporting a plausible number for something other than what was asked.

Verified with a scan against the scratch key rather than by reasoning about the config. The analysis now records version 1.0.0, ncloc holds at 5557 so nothing was silently dropped, and new_lines falls from the whole codebase to 151 — the window is now the diff.

One consequence worth expecting rather than discovering: a narrow window makes new_coverage volatile. The verification scan reported 0.0% on two lines to cover, because two uncovered lines is all it takes. The number will settle as commits accumulate and the window widens, but the gate will be jumpy for the first few merges, and it will not simply turn green on its own.

Left at 1.0.0 to match both package.json files. Nothing enforces that they stay in step, so the comment says to move all three together.

Refs #79
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

sonar-project.properties

@@ -8,6 +8,22 @@ sonar.sources=backend/src,frontend/src
 sonar.exclusions=**/node_modules/**,**/dist/**
 sonar.sourceEncoding=UTF-8
 
+# The new-code period. Without this the gate silently grades the entire codebase
+# rather than what changed: the server's period is PREVIOUS_VERSION, and with no
+# version ever declared there is no previous version to diff against, so every
+# line counts as new. The symptom is new_lines (9460) exceeding total ncloc
+# (5496) and new_coverage tracking overall coverage to within two points, which
+# looks like a working gate right up until you check. See #79.
+#
+# PREVIOUS_VERSION baselines at the first analysis carrying a given version, so
+# "new code" here means everything since this number last changed. Bump it when
+# a release is cut and the baseline moves with it; leave it alone and the window
+# simply keeps widening, which is the honest behaviour rather than a silent one.
+#
+# Kept in step with the version in backend/package.json and frontend/package.json
+# by hand. Nothing enforces that, so change all three together.
+sonar.projectVersion=1.0.0
+
 # Without this the analyser auto-discovers frontend/tsconfig.json, chokes on its
 # "moduleResolution": "bundler" — unrecognised by the TypeScript bundled with
 # SonarQube 9.9 — and silently drops all 34 frontend files while still exiting