fix(security): scan for secrets with the version the project pins

[ttncode]

What this changes

The gitleaks job in you/.github's security workflow ran gitleaks/gitleaks-action. It now runs mise run secrets — a task in the generated project's own mise.toml, using the gitleaks that project already pins for its commit hook. scaffold publish additionally turns on GitHub's native secret scanning and push protection where the plan allows.

Why

The action builds its scan range as <first commit of the push>^..<last>. On a repository's first push that first commit is the root commit, which has no parent:

gitleaks cmd: … --log-opts=--no-merges --first-parent ca9c409…^..f26976e…
ERR [git] fatal: ambiguous argument 'ca9c409…^..f26976e…': unknown revision
ERR failed to scan Git repository error="stderr is not empty"
WRN scanned ~0 bytes (0)
WRN no leaks found in partial scan

Reproduced deterministically in an isolated repository: first push red having scanned nothing, second push green. I had recorded this earlier in the session as "an intermittent gitleaks failure" and moved on; it is not intermittent, and the red was never the problem. The problem is a scan that did not happen reporting "no leaks found" — on exactly the push that first puts a project's whole history on GitHub.

v3.0.0 is the action's latest release and is what we pinned, so there was nothing to bump to.

Second, quieter: the action downloaded gitleaks 8.24.3 while generated projects pin 8.30.0. The commit hook and CI were scanning with different versions.

Why this shape

immich runs no secret scanner in CI at all — it relies on GitHub's own secret scanning and push protection — and runs every other tool through mise run <task> rather than a per-tool wrapper action (mise run ci-publish, mise run //docs:deploy, mise //:release). Both halves apply:

• Native scanning blocks a secret at push time, before it lands. That is the better control, and scaffold publish now enables it.
• It needs Advanced Security on a private repository, and generated client projects are private — so CI keeps a scan, run the way every other tool in this ecosystem is run. One pinned version, whole history, no range arithmetic to get wrong.

How it was verified

Generated a project, published it, and watched the real workflow:

push	before	after
first (root commit)	red, scanned ~0 bytes	green, 1 commits scanned, ~103474 bytes
commit with a planted ghp_… token	—	red, 3 commits scanned, leaks found: 1

A gate that cannot fail is worth nothing, so the second row is the one that matters. The verification repository and its package have been deleted.

you/.github side merged as ttncode/.github#3; v1 moved to v1.2.0.

Checklist

• mise run lint passes
• mise run test-runner passes
• New behaviour has a test that fails without the change
• Docs that describe changed behaviour were updated in the same commit
• No unrelated changes