Add code scanning over this repository's own language

[iderex]

The target gate runs three code-scanning analyses and reports them as
Analyze (actions), Analyze (csharp) and Analyze (javascript-typescript).
This repository has one language and its workflows, so the shape differs while
the property does not.

The deviation and its reason: fewer analyses, because there are fewer languages
here, and the workflow analysis is kept because this repository has workflows
that publish artifacts.

What this produces

Code scanning over the repository's own language and over its workflow
definitions, uploading to the code-scanning surface and failing the gate on an
actionable finding rather than only reporting one.

A stated position on findings that are not fixed, which is the machine-readable
statement in #89 rather than an ignored alert.

Done when

The analysis runs on every pull request and on push to main, the leg refuses a
report carrying a finding rather than only reporting one, and the check-run names
are recorded in the table in #80.

REWRITTEN 2026-08-31, AND THE CONDITION IT REPLACES WAS WIDER. It read that a
deliberately introduced finding of the kind the analysis is meant to catch
reddens it. Two such defects were written against the loaded queries and
reverted, once in #195 before this crate declared a dependency and once on the
branch of #223 after it did, and both runs reported nothing. The query pack is
fetched at run time rather than tracked here, so that condition waited on
something outside this repository that nobody had undertaken to move and that no
reading of this tree could settle either way. What this leg can prove from here,
and does, is that it refuses a report carrying a finding.

WHAT THAT DOES NOT PROVE IS THAT THE LOADED PACK FINDS A DEFECT OF THIS KIND IN
THIS LANGUAGE. The two attempts above are what establish that this is unproven
rather than assumed, and the narrower condition is not a claim that the wider one
holds.

The two blockers this issue carried are closed and the labels came off on
2026-08-25.

[iderex]

Two things in the body are worth correcting before this is built, and one of them
narrows what it waits on.

The reason given for keeping the workflow analysis is that this repository has
workflows that publish artifacts. Nothing here does. There are seven workflow
files, none of them named for a publish, no trigger on a tag or a release, and the
repository has published nothing:

git rev-parse HEAD
f8ee6102cd4436ad294e684e55fe91170a34283e
git ls-files .github/workflows | wc -l
7
git ls-files '.github/workflows/publish*' | wc -l
0
git grep -nE '^\s{2,4}(release|create):|tags:' -- .github/workflows/ ; echo "exit=$?"
exit=1
gh api repos/Flowfin/core/releases --jq 'length'
0

Whether anything is published at all is entry 6 of #1 with #94, so that reason
becomes true only under one of the answers there. The workflow analysis is still
worth keeping, and the argument that survives is a different one: workflow YAML is
executable configuration in a tree that carries seven files of it, whatever it
publishes.

The same inherited sentence is in the tree, inside the file it is about:

git grep -n 'publish-beta.yml' -- .github/workflows/zizmor.yml
.github/workflows/zizmor.yml:2:# workflow YAML is release-critical attack surface - publish-beta.yml runs on
git ls-files '.github/workflows/publish*' | wc -l
0

A reader following that comment looks for a file this tree does not carry. I have
not changed it. That sentence arrived with the workflow rather than with this
issue, and correcting it is a change to a file this issue does not produce.

The second thing narrows the wait. Analysis over the workflow definitions does not
depend on which language the core is written in, because those files are here now,
and the codeql.yml row in docs/gate-parity.md already reads it that way for the
analysis that names actions. What that half would arrive into is not an empty
surface. Static analysis over these same files runs here today and reaches the same
code-scanning surface:

git grep -ln 'upload-sarif' -- .github/workflows/
.github/workflows/scorecard.yml
.github/workflows/zizmor.yml

docs/gate-parity.md records Audit workflows (zizmor) as satisfied on the
strength of that. The two do not look for the same defects and I am not claiming
they do. What follows is narrower: adding the analysis that names actions here
puts a second analyser over files a first one already reads, which is a different
argument from the one the body makes and is the one that has to be made before it
lands.

The half over the core's own language is untouched, and what it waits for has not
moved.