chore(ci): add scheduled dependency-audit scan against dev

[parthrohit22]

Summary

The `Frontend` job's live `npm audit` gate (`scripts/dependency-audit.mjs`) blocks every PR on whatever the GitHub Advisory Database looks like at the exact moment CI runs — not on the PR's own diff. Three unrelated PRs went red today from newly published CVEs within a few hours of each other (#256, then a fresh nanoid advisory blocking #259's rebuild, tracked together as the trigger for #258/#263). Owner-selected fix (of three options presented): keep the per-PR gate exactly as strict as today, and add a scheduled scan against `dev` so it rarely gets the chance to blindside an unrelated PR in the first place.

Linked issue

Closes #263

Roadmap alignment

CI/process reliability, not a product capability — doesn't map onto a §23/§28 citation, same pattern as #257/#259.

• Roadmap §23 workstream this advances: none directly.
• §28 market-fit criterion this moves toward: not directly applicable.
• Accepted evidence it is real: three real same-day CI failures on unrelated PRs (feat(frontend): add non-visual architecture graph list view (#239) #255, fix(infra): fix backend Docker build cache invalidation and missing .dockerignore #259) traced to this exact mechanism; the fix directly targets the mechanism, not a symptom.

What changed

New `.github/workflows/dependency-audit-schedule.yml`:

• Triggers on a daily cron (`17 6 * * *`) plus `workflow_dispatch` for manual runs.
• Checks out `dev`, installs frontend deps, runs `node scripts/dependency-audit.mjs`, capturing output and exit code.
• On a blocking finding: ensures a `dependency-audit-alert` label exists (idempotent, `--force`), then either creates a new issue (assigned to `@parthrohit22`) or comments on an already-open one — so a still-unresolved advisory doesn't spam a new issue every day.
• On a clean result: comments on and closes any currently-open alert issue (self-healing once the advisory is actually fixed).

Does not touch `ci.yml` or the existing per-PR `Frontend` job at all — the per-PR gate keeps its current strictness unchanged; this is purely additive.

Acceptance criteria completed

• New scheduled workflow exists, does not affect `ci.yml`'s existing per-PR gate
• A manual `workflow_dispatch` run completes successfully against the current (clean) `dev` state — could not verify before merge, see Testing performed
• Issue-filing logic reviewed for idempotency (checks for an already-open `dependency-audit-alert`-labelled issue before creating a new one)

Testing performed

python3 -c "import yaml; yaml.safe_load(open('.github/workflows/dependency-audit-schedule.yml')); print('YAML OK')"
  -> YAML OK

gh workflow run dependency-audit-schedule.yml --ref chore/263-scheduled-dependency-audit
  -> HTTP 404: workflow dependency-audit-schedule.yml not found on the default branch

GitHub Actions' `workflow_dispatch` requires the workflow file to already exist on the repository's default branch (`main`) before it can be manually triggered — a genuine chicken-and-egg limitation for testing a brand-new workflow pre-merge, not something resolvable from this branch. I validated the YAML syntax and manually reviewed the `gh issue`/`gh label` logic and `GITHUB_TOKEN` permissions (`issues: write` declared), but have not seen it execute for real. Recommend triggering it once manually via `gh workflow run dependency-audit-schedule.yml` right after this merges, to confirm the clean-`dev` path runs end-to-end before trusting the cron.

Screenshots

Not applicable — CI workflow change, no UI impact.

Security and data considerations

Uses the automatic `GITHUB_TOKEN` (scoped via the `permissions:` block to `contents: read`, `issues: write` only — no write access to code, no secrets referenced). No new dependency, no new external service, no change to what's exposed or how the existing per-PR audit gate behaves.

Dependencies and blocked work

None.

Scope changes or remaining work

Per the "Testing performed" note above: a real post-merge `workflow_dispatch` run confirming the clean-`dev` path (comment/close logic untriggered since nothing's currently open) is the actual verification step for this PR's second acceptance criterion, and can't happen before merge. Flagging explicitly rather than claiming it as done.

Contributor checklist

• This PR targets `dev`
• I claimed the issue and had it assigned before starting substantial work (self-assigned chore(ci): add scheduled dependency-audit scan against dev, independent of open PRs #263; not commented per maintainer instruction)
• The branch was created from an up-to-date `upstream/dev`
• The branch is rebased on the latest `upstream/dev`
• This PR addresses one clearly scoped issue
• This PR advances a §23 workstream toward a §28 market-fit criterion — see honest Roadmap alignment note above; this is CI/process reliability, not a product change
• Every acceptance criterion I claim as complete is actually complete — one left unchecked and explained above, not claimed
• Relevant tests pass — no automated test suite covers GitHub Actions workflows; verified via YAML validation and manual code review, disclosed above
• Documentation is updated for any user-visible change — none needed, no documented behavior changed
• No secrets, credentials, local env files, or generated artifacts are included
• No unrelated files were changed
• Closing syntax (`Closes`) is used only because the issue is fully resolved
• Dependencies and follow-up work are linked