Feature Request: Add scheduled full-repo sweep to lint-format.yml (similar to links.yml)

`lint-format.yml` only runs its full-repo scan on a direct push to `main` — a path the PR-based contribution workflow outlined in `CONTRIBUTING.md` essentially never triggers. In practice, the check has only ever verified PR diffs, never the tree's actual current state.

I noticed this while pushing the full repository history to a private fork. Because it was a direct push rather than a PR, it hit the workflow's full-scan fallback and surfaced 25 pre-existing `ruff` findings across 6 files. None of these had ever failed CI on `main` because no single PR diff had ever contained them together.

Most were false positives on inspection. One wasn't: `run_shell_command` in `03_The_site_reliability_agent.ipynb` validates only the executable name (`docker`/`docker-compose`), not the subcommand — so a command like `docker run --privileged -v /:/host ...` passes unmodified. `sre_mcp_server.py`, added in the same original PR (#391), already implements the stricter subcommand allowlist; the two were never reconciled.

## Why this matters beyond that one finding

To be precise: a scheduled scan would not have caught that gap directly. `ruff` cannot evaluate whether validation logic is semantically adequate; it only checks if a call shape matches a rule.

What the scan did do is place a generic, mostly-false-positive `S603` warning on that exact line. This prompted a close enough read to catch the real issue by comparing it against the sibling file. The value wasn't automated detection — it was forcing a human review that otherwise had no trigger at all.

Without a periodic full-repo pass, nothing prompts anyone to look at untouched files again, lint-detectable or not. A cookbook repo whose purpose is demonstrating good practice has more reason than most to avoid modeling that gap in its own tooling.

## Proposed Solution

Add a scheduled trigger and manual dispatch to `lint-format.yml`, mirroring the pattern already established by `links.yml` for the analogous link-rot problem:

```yaml
on:
schedule:
- cron: "0 0 * * SUN"
workflow_dispatch:
```

This reuses the full-scan path that already exists in the workflow — no new scanning logic required.

## Implementation Considerations

A scheduled run has no PR to attach a failure to, so it needs a different reporting path than blocking a merge:

- Let it fail natively on the Actions tab for maintainers to review periodically, or
- Auto-open/update a tracking issue on failure.

Would maintainers be open to adding this? Happy to open a quick PR for the workflow change if the general direction is welcome.