No end-to-end coverage that the job worker establishes the dispatched-operation carrier

## The gap

`server/jobs/jobProcess.ts` establishes the dispatched API operation on async context (`runWithDispatchedOperation`) before invoking a job's handler. That carrier is what makes an export job's nested SQL scope-checked as `export_local` rather than as the inner `sql` — see the `DESIGN.md` section "The dispatched API operation is carried on async context, never on the request".

Nothing tests that `jobProcess.ts` actually establishes it. The unit tests in `unitTests/security/tokenOperationScope.test.js` call `runWithDispatchedOperation` themselves, so they pin the carrier's *contract* but would stay green if the `jobProcess.ts` call were deleted — at which point every `export_local`-scoped credential would start being refused on its own export, silently as far as CI is concerned.

## Why it wasn't covered

The carrier is only observable through `tokenScopeDenial`, which is inert unless the principal carries `tokenOperations`. That property has exactly one origin: an OIDC trust-policy exchange (`security/authn/oidc/tokenExchange.ts`, #2174). Specifically:

- A **scoped token** (`create_authentication_tokens` with an inline `role` object) is always minted `super_user: false` (`security/tokenAuthentication.ts`), and `export_local` is `requires_su` — so that route can never reach an export at all.
- The reachable production shape is an OIDC-exchanged token for a real super_user whose trust policy sets `operations`.

There is no OIDC integration-test harness — OIDC is unit-tested only (`unitTests/security/authn/oidc/`) — and standing one up needs a live JWKS issuer.

## Also uncovered in the same function, for the same reason

`server/jobs/jobProcess.ts` deletes a persisted `parsed_sql_object` (both the top-level and the
nested `search_operation` position) when it loads the row, so a job queued before the dispatch-time
strip existed — or a row written directly into `system.hdb_job` — cannot execute an AST carrying
`permissions_checked: true` that no check ever saw. That line has no direct test either, and for the
same reason: `jobProcess.ts` is a top-level worker IIFE keyed off `process.env`, so it is not
reachable in isolation. Its dispatch-time twin **is** covered, by
`unitTests/server/serverHelpers/serverUtilities.test.js`'s `discards a body-supplied
parsed_sql_object on the nested search_operation`.

So whatever makes `jobProcess.ts` testable closes two untested branches in one function, not one.

## What would close it

Either an OIDC integration harness (reusable well beyond this), or a narrower seam test that drives `jobProcess.ts`'s handler invocation directly and asserts the carrier is in scope.

Found while making `processAST` honor the permission denial it computes (#2202).

Start with server/jobs/jobProcess.ts and the existing tests in unitTests/security/tokenOperationScope.test.js and unitTests/server/serverHelpers/serverUtilities.test.js. Determine whether a seam test or an OIDC harness can exercise the worker handler, then cover the async dispatched-operation carrier and persisted parsed_sql_object deletion paths. Done means both branches are asserted without requiring an unmentioned implementation.

Written by the indexing model from the issue text.