Add the pull-request check named dependencies, with a committed lockfile and a locked restore

[iderex]

A dependency graph that resolves freshly on every build is a graph that can
change between a contributor's machine and the gate, and between two gate runs an
hour apart. The repository already runs GitHub's dependency review on pull
requests, which reads the diff against the advisory database. That is a different
question from whether the graph the build actually resolved is the graph that was
committed.

What the check does

Restores in locked mode, so a restore that would rewrite the committed lockfile
fails rather than proceeding quietly.

Scans the resolved graph for known vulnerabilities and fails on a match. The step
uses set -o pipefail where its verdict comes through a pipe, because the
default shell for a bare run: is bash -e without it, and a gate whose exit
status is the last command in a pipe is a gate that passes on everything.

Reports what it examined, including the number of packages, so a scan that
resolved nothing cannot read as a scan that found nothing.

Done when

A workflow exists whose check-run name is exactly dependencies, a
deliberately drifted lockfile fails it, a fixture with a known-vulnerable
dependency fails it, and the lockfile is committed and covered by the build.
Blocked on #11, and on #103 for what is allowed into the graph this check
reads, since a check with no rule behind it can only report the advisories
somebody else published.

[iderex]

The sentence in the body about what already runs here is true of the workflow file
and false of what the workflow does. dependency-review does not read the diff
against the advisory database on this repository. It stops before reading anything:

gh run view 31278612422 --log-failed
##[error]Dependency review is not supported on this repository. Please ensure that Dependency graph is enabled

That is the only run the workflow has ever had here, so it has never passed:

gh run list --workflow "Dependency review" --limit 30 --json databaseId,conclusion,event,createdAt --jq '.[] | "\(.databaseId) \(.event) \(.conclusion) \(.createdAt)"'
31278612422 pull_request failure 2026-08-08T21:08:58Z

Two consequences for this issue.

The premise narrows rather than widens. The gap this issue exists to close was
described as the difference between reading a diff against an advisory database and
proving the resolved graph is the committed one. Today there is no advisory reading
either, so the check named dependencies is the only dependency check this board
would have, and it carries both halves rather than one.

The condition is not in the tree. The dependency graph is a repository setting, so
nothing on a branch turns that check green, and every pull request against this
board is red until it is on. It is also visibly off from outside:

gh api repos/Flowfin/core --jq '.security_and_analysis'
{"dependabot_security_updates":{"status":"disabled"},"secret_scanning":{"status":"disabled"},"secret_scanning_non_provider_patterns":{"status":"disabled"},"secret_scanning_push_protection":{"status":"disabled"},"secret_scanning_validity_checks":{"status":"disabled"}}

dependabot_security_updates reads as disabled in the same answer, which #108
depends on.

Nothing here changes what this issue is blocked on. It still waits on #11 for the
toolchain that has a lockfile at all, and on #103 for the rule the scan is read
against.

[iderex]

The dependency graph is on now, and the two commands quoted above answer
differently at this commit.

Every run the workflow has had here, not one:

gh run list --workflow "Dependency review" --limit 30 --json databaseId,conclusion,event,createdAt --jq '.[] | "\(.databaseId) \(.event) \(.conclusion) \(.createdAt)"'
31305879878 pull_request success 2026-08-09T09:25:41Z
31305437465 pull_request success 2026-08-09T09:14:42Z
31297501486 pull_request success 2026-08-09T05:48:52Z
31292603519 pull_request success 2026-08-09T03:31:33Z
31291892245 pull_request success 2026-08-09T03:10:36Z
31278798050 pull_request success 2026-08-08T21:13:33Z
31278612422 pull_request success 2026-08-08T21:08:58Z

31278612422 is the run quoted above as the only one and as a failure. It is the
same run and it now concludes success, on a second attempt started after the
first one ended:

gh api repos/Flowfin/core/actions/runs/31278612422 --jq '{run_attempt, conclusion, run_started_at}'
{"conclusion":"success","run_attempt":2,"run_started_at":"2026-08-08T22:25:05Z"}

The endpoint the action was refused by answers rather than refusing:

gh api repos/Flowfin/core/dependency-graph/sbom --jq '.sbom.packages[] | "\(.name)\t\(.SPDXID)"'
com.github.Flowfin/core	SPDXRef-github-Flowfin-core-main-85f2d8

That is one package and it is this repository itself, because no manifest is
committed yet, so what those runs read the diff against is an empty set of
dependencies. A green run today says the action works here, and it says nothing
about a graph, because there is no graph to say anything about.

Two things follow.

The premise widens back to the one the body states rather than staying narrow.
Advisory reading over the pull-request diff runs on this repository, so the check
named dependencies carries the half the body describes, proving that the graph
the build resolved is the graph that was committed, rather than carrying both
halves alone.

The condition is still not in the tree, and one field in that answer has not
moved:

gh api repos/Flowfin/core --jq '.security_and_analysis'
{"dependabot_security_updates":{"status":"disabled"},"secret_scanning":{"status":"enabled"},"secret_scanning_ai_detection":{"status":"disabled"},"secret_scanning_delegated_alert_dismissal":{"status":"disabled"},"secret_scanning_delegated_bypass":{"status":"disabled"},"secret_scanning_non_provider_patterns":{"status":"disabled"},"secret_scanning_push_protection":{"status":"enabled"},"secret_scanning_validity_checks":{"status":"disabled"}}

dependabot_security_updates still reads as disabled, which is what #108
depends on. Secret scanning and its push protection now read as enabled and did
not in the answer quoted above.