ci(security): commit Cargo.lock and add the osv-scanner job

[forkwright]

logismos reported cargo audit and cargo deny but no OSV scan — it saw RustSec advisories and not the broader OSV database. It is the third of three repos closing that gap today (koinon#51, epitelesis#32).

Why this PR is bigger than the other two

Adding the fleet's osv-scanner job needs a lockfile. Its scan-args name Cargo.lock, and the scanner does not generate one — pointed at a tree without it, the job fails on every run, on every PR and on the daily schedule. Not intermittently. Always.

So the lockfile is the actual fix, and the honest question is whether it should have been committed anyway.

The ignore was inherited, not decided

# Cargo
Cargo.lock

A bare line under a bare heading, with no stated reason, arriving in 616e646 chore(repo): public snapshot — i.e. it came in with the initial import rather than from a decision about this repo.

Against that:

• logismos is a workspace (members = ["crates/*"]), and every other Rust workspace in the fleet — sphragis, koinon, epitelesis — commits its lockfile.
• Current Cargo guidance recommends committing lockfiles for libraries too; the older "libraries don't" advice was reversed upstream.
• --locked builds are not reproducible without it.

The .gitignore now records why it is committed, so the next reader does not have to reconstruct this reasoning from a commit message.

Approach: the reusable workflow, not the scanner action

I checked the alternative first. google/osv-scanner-action's own action description says:

We recommend using the reusable workflows instead of directly using the scanner action as the scanner action behavior might change in a minor patch update.

Using the action directly would have let me inject a cargo generate-lockfile step and avoid committing anything — but it means adopting a surface the maintainers explicitly warn is unstable, and inventing a bespoke job shape for one repo. Committing the lockfile lets logismos use the same job every other repo uses, pinned at the same SHA.

What this does not change

No dependency version moves here. The generated lockfile resolves 146 packages and pins what is already in use:

rand 0.8.7        (0.10.2 available)
safetensors 0.7.0 (0.8.0 available)
snafu 0.8.9       (0.9.2 available)
tokenizers 0.22.2 (0.23.1 available)

Each already has a dependabot PR open against this repo. Those will regenerate the lockfile as part of their own diffs, which is the intended interaction rather than a conflict.

What I could not verify

The workflow has not run. Whether cargo deny, cargo audit and the OSV scan pass against this newly-committed lockfile will be visible on this PR's own checks — and if OSV surfaces an advisory, that is the job working, not the PR failing.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.