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, a deliberately
introduced finding of the kind it is meant to catch reddens it, and the check-run
names are recorded in the table in #80. Blocked on #11 and #80.

[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.