Restore the quality gate as blocking

[matt-edmondson]

Removes the temporary continue-on-error from the End SonarQube step, closing #328.

Why it was there

The workflow sets sonar.qualitygate.wait=true, so a failed quality gate fails the step and blocks the release. That could not take effect usefully while the new-code period was meaningless.

SonarCloud's period was correctly set to "previous version", but the scanner was never passed /v:, so the project version read as not provided and the period had no boundary to anchor to. It fell back to the earliest analysis, dated 2025-07-30, which made "new code" 49,630 lines and turned the new-code coverage condition into a measure of the entire codebase. Reaching 80% under that definition would have meant covering roughly 1,538 more lines. It was never a testing gap.

Passing /v: fixed the cause, and it needed two analyses to take effect, because "previous version" needs a prior analysis carrying a different version.

It has taken effect

v3.11.0 supplied the second boundary:

	Before	Now
Project version	not provided	3.11.0
Leak period start	2025-07-30	2026-08-23
new_security_rating	3	1
new_security_hotspots_reviewed	0.0%	100%
new_coverage	65.4% against 80%	no longer applies
Gate	ERROR	OK

The two security conditions were fixed separately, by pinning dependabot/fetch-metadata to a commit SHA and by suppressing a csharpsquid:S6640 on Sequencer.cs where the pointer lifetime is provably scoped to its fixed block.

What changes

A failed quality gate now blocks the release, for the first time genuinely, since the gate is at last measuring the code a change actually touched rather than thirteen months of history.

The escape hatch and its comment block are gone. actionlint reports 0 errors.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud