improvement(ci): scan CodeQL PRs at the promotion boundary, refresh main daily (#7213)

Feature PRs land on staging and are ~90% of PR scan volume (90 of the last 100
PRs target staging, 4 target main). Every one of them is scanned again — against
the exact tree being promoted — when the staging->main PR opens, so restricting
PR scans to main defers the signal to the promotion boundary rather than
dropping it. No ruleset or branch protection requires a CodeQL check, and the
alert view is fed by the push-to-main and scheduled analyses, not by PR runs.

Deliberately a branch cut rather than an activity-type cut. Dropping
`synchronize` would have cut a similar share of runs, but it scans a PR's first
commit and never its final state — backwards, since review fixups land in later
pushes.

The scheduled scan moves from weekly to daily. Pushes to main are rare, so with
PR scans limited to main the default-branch alert view leans on the cron more
than it used to, and a week is too long to leave it stale. It also reseeds the
overlay-base database that PR runs restore from: that cache key embeds the
CodeQL bundle version, so a bundle bump invalidates it, and an unused Actions
cache is evicted after 7 days.

Also records, in codeql-config.yml, why the obvious speed-up is a trap: adding
`queries:`/`packs:`/`query-filters:` trips OverlayDisabledReason.NonDefaultQueries
and permanently disables overlay analysis, trading a documented up-to-10x win on
the extraction phase (~53% of a run) for a few percent off the query phase.

Author: waleedlatif1

.github/codeql/codeql-config.yml

@@ -31,3 +31,11 @@ paths-ignore:
   - '**/dist/**'
   - '**/.next/**'
   - 'apps/docs/content/**'
+
+# Do NOT add `queries:`, `packs:`, `query-filters:`, or `disable-default-queries`
+# here to try to speed the scan up. Under the code-scanning feature flag the
+# action's checkOverlayAnalysisFeatureEnabled treats any of those as
+# OverlayDisabledReason.NonDefaultQueries and permanently turns off overlay
+# (incremental) analysis. Extraction is ~53% of a run and is exactly what overlay
+# skips, so scoping the queries trades a documented up-to-10x win for a few
+# percent off the 27% query phase.

.github/workflows/codeql.yml

@@ -20,8 +20,16 @@ on:
   # created, prevents developers from introducing new vulnerabilities."
   push:
     branches: [main]
+  # main only, not staging. Feature PRs land on staging and are ~90% of PR scan
+  # volume, and every one of them is scanned again — against the exact tree being
+  # promoted — when the staging->main PR opens. Scanning at the promotion
+  # boundary defers the signal rather than dropping it.
+  #
+  # Deliberately a branch cut and not an activity-type cut: dropping
+  # `synchronize` would have scanned each PR's first commit and never its final
+  # state, which is backwards, since review fixups land in later pushes.
   pull_request:
-    branches: [main, staging]
+    branches: [main]
     # `ready_for_review` is not a default activity type, so it has to be listed
     # alongside the defaults it replaces. Without it, a PR opened as a draft and
     # then marked ready is skipped by the job-level draft guard and never
@@ -41,7 +49,15 @@ on:
     # Safety net behind the push trigger, and the thing that keeps the
     # default-branch alert view fresh when main is quiet. Only fires once this
     # file is on the default branch — schedule events ignore other branches.
-    - cron: '17 8 * * 1'
+    #
+    # Daily rather than weekly. Pushes to main are rare, and with PR scans now
+    # limited to main the alert view leans on this more than it used to; a week
+    # is too long to leave it stale. It also reseeds the overlay-base database
+    # that PR runs restore from — that cache key embeds the CodeQL bundle
+    # version, so a bundle bump invalidates it, and an unused Actions cache is
+    # evicted after 7 days. One 8 vCPU default-branch scan a day is a few
+    # dollars a month against a PR scan that halves when the base is warm.
+    - cron: '17 8 * * *'
   workflow_dispatch:
 
 concurrency: