Every branch's CI scan overwrites the SonarCloud project state #154

Found while dismissing the first scan's false positives.

The sonar job runs the scanner with no -Dsonar.branch.name, so every analysis is recorded against the project's main branch whatever branch produced it. The job runs on every push, so a feature branch's result replaces main's.

It is not theoretical. Right now the dashboard reflects 319867a, the head of an unmerged branch (!257), because that branch's CI ran most recently. Two go:S4036 findings that are open on main show as FIXED, on the strength of a commit main does not contain.

Both directions are wrong. A branch that removes findings makes main look clean before the fix is merged, and a branch that adds them makes main look broken when it is not — and the quality gate, once it gates rather than reports, would follow the wrong one.

Remedy, either:

• Pass -Dsonar.branch.name="$GITBAY_REF" so each branch is analysed as itself and main keeps its own history. SonarCloud shows branch results separately and this is what the feature is for. Note the runner exports GITBAY_REF already.
• Or run the job only on the default branch, if per-branch analysis is not wanted. Cheaper, but loses the ability to see what a merge request would do to the numbers, which is most of the point of scanning on a branch at all.

The first is the better answer if merge requests are ever meant to be gated on it.

Also worth deciding alongside: the scan currently runs on every push including tags and the changelog commits, which is three or four analyses per release for identical source.