docs: point comments at the queue table's home and fix a bench note

Four comments still named `queue-runtime.ts` without its folder after it
moved under src/__tests__/helpers/, and the v1.45.0 boot page described
two dumps that are no longer kept.

scripts/bench/results/v1.45.0-boot.md

@@ -1,9 +1,9 @@
 # v1.45.0: boot and idle memory
 
 `scripts/bench/boot-profile.ts`, production build, every role, heap ceiling
-792 MB, against the seeded account, 300 s idle. `v1.45.0-before-boot` is the
-v1.44 runtime, `v1.45.0-boot-after` the branch after the boot changes and
-before the lazy match indexes, `v1.45.0-boot-final` the final tree.
+792 MB, against the seeded account, 300 s idle. "before" is the v1.44 runtime
+(`v1.45.0-before-boot.md`), "final" the v1.45.0 tree; its raw dumps are not
+kept.
 
 | | before | final |
 | --- | ---: | ---: |

src/lib/insights/status-provider.ts

@@ -49,8 +49,9 @@ export const REASONING_JOB_TIMEOUT_MS = 90_000;
  * a thinking model whose first answer was reasoning alone timed out in the
  * middle of the repeat that would have answered, and a slow local model the
  * person had given 300 s or more per call never landed its note (#1274).
- * Every caller is a background job; the job expiries in `queue-runtime.ts`
- * sit above this at the largest setting.
+ * Every caller is a background job whose queue expiry sits above this at the
+ * largest setting (the queue table in `src/__tests__/helpers/queue-runtime.ts`
+ * holds it there).
  */
 export function statusRunBoundMs(effectiveTimeoutMs: number): number {
   return effectiveTimeoutMs * STATUS_MODEL_CALLS;

src/lib/jobs/document-ai-run.ts

@@ -18,11 +18,11 @@
  *   4. runs the same body the synchronous route runs, and stores the result
  *      or the failure the route would have answered with.
  *
- * The queue is `long` (`queue-runtime.ts`): a read at the longest response
- * setting outlasts pg-boss's fifteen-minute default. Each job runs under the
- * lock `lockedPass` takes per run, and is sent with `retryLimit: 0`: a run
- * the worker lost is failed by the reaper and asked for again by the person,
- * never re-run behind their back.
+ * The queue is `long` (`src/__tests__/helpers/queue-runtime.ts`): a read at
+ * the longest response setting outlasts pg-boss's fifteen-minute default.
+ * Each job runs under the lock `lockedPass` takes per run, and is sent with
+ * `retryLimit: 0`: a run the worker lost is failed by the reaper and asked
+ * for again by the person, never re-run behind their back.
  *
  * The queue MUST be registered in the maintenance registrar
  * (`src/lib/jobs/reminder/register-maintenance.ts`) so pg-boss provisions it.

src/lib/jobs/long-pass.ts

@@ -1,8 +1,8 @@
 /**
  * The binding for a queue whose job can outlast pg-boss's default expiry.
  *
- * Three things together make a long job safe, and `queue-runtime.ts` names
- * every queue that needs them:
+ * Three things together make a long job safe, and the queue table in
+ * `src/__tests__/helpers/queue-runtime.ts` names every queue that needs them:
  *
  *   1. An explicit `expireInSeconds` on every send and schedule, so pg-boss
  *      does not declare the job dead at fifteen minutes while it is working.

src/lib/jobs/model-time.ts

@@ -7,8 +7,9 @@
  * bound. pg-boss fails and retries a job that runs past its expiry, and it
  * does not stop the handler, so an expiry below that work lets a retry run
  * beside the first attempt (#1274). The bounds here are what the outer aborts
- * use and what the expiries in `queue-runtime.ts` are derived from, so both
- * move together when a call count or the setting's ceiling does.
+ * use and what the queue expiries are derived from (the queue table in
+ * `src/__tests__/helpers/queue-runtime.ts` checks them), so both move
+ * together when a call count or the setting's ceiling does.
  *
  * No server import: the queue modules that carry an expiry into a send read
  * these without loading a generator.