ci(security): add osv-scanner job to security workflow

[forkwright]

What was missing

epitelesis's .github/workflows/security.yml ran cargo-deny and
cargo-audit but had no OSV scan, so it only ever saw RustSec advisories,
not the broader OSV database.

What I added

One new job, osv-scanner (display name osv scanner), appended after the
existing cargo-audit job — nothing else in the file was touched. It's
copied verbatim from sphragis's security.yml, which is the only fleet
repo currently proven to report all four check groups the org auto-merge
workflow waits on:

osv-scanner:
  name: osv scanner
  uses: google/osv-scanner-action/.github/workflows/osv-scanner-reusable.yml@9a498708959aeaef5ef730655706c5a1df1edbc2
  permissions:
    actions: read
    contents: read
    security-events: write
  with:
    scan-args: '--config=osv-scanner.toml --lockfile=Cargo.lock'

The commit SHA pin (9a498708959aeaef5ef730655706c5a1df1edbc2) is copied
verbatim from sphragis, not re-resolved — an unpinned or differently-pinned
action would be a supply-chain difference, not a formatting one.

epitelesis already had a matching osv-scanner.toml at repo root (with a
header noting it's derived from deny.toml [[advisories.ignore]] via
kanon audit derive-ignores --apply) and a root Cargo.lock, so the
scan-args reference both correctly with no other repo changes needed.

sphragis vs. kanon's template — where they differed, and which I took

The kanon template (workflow/templates/ci/security.yml) also defines an
osv-scanner job at the same pinned SHA, but with one difference: it sets
upload-sarif: false explicitly under with:. sphragis's version omits
that key (using the reusable workflow's default). Per the task instructions
to prefer sphragis where the two disagree, I took sphragis's form
(no upload-sarif override). I did not investigate what the reusable
workflow's default resolves to, so if epitelesis wants SARIF upload
suppressed the same way kanon's template does, that's a follow-up, not
something this PR silently decided.

The kanon template also carries additional jobs (secret-scan via
TruffleHog, gitleaks) that neither sphragis nor epitelesis have. Per
task scope ("add ONLY the osv-scanner job... do not restructure the jobs
that already work"), I left those out — not proposing them here.

What I could not verify

I did not and could not run the workflow in GitHub Actions from this
worktree (box-shared, no build/CI access per task constraints). YAML
syntax validity was confirmed locally (yaml.safe_load succeeds), and the
diff is confirmed purely additive via git diff, but whether the job
actually executes green — e.g. whether osv-scanner.toml's IgnoredVulns
list needs entries once the scan actually runs against epitelesis's real
dependency tree — is unverified and should be checked on the first CI run
after merge.

Note on gate check naming

epitelesis's gate check is gate / gate-attestation, not gate / gate
like other repos — this PR doesn't touch that, just flagging per task
instructions that I did not assume the other spelling exists anywhere in
this change.

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