Merge pull request 'chore(ci): declare sonar.projectVersion so the new-code period means something (#79)' (#80) from feature/79-sonar-project-version into main

Reviewed-on: #80

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