fix(security): authorize the invoked operation against the authenticated principal

DESIGN.md

@@ -1899,3 +1899,19 @@ degrades to the historical behavior rather than replacing it. Invariants that ar
 ## A worker that misses an ITC ack gets its OS thread state logged (`server/threads/manageThreads.js`)
 
 `broadcastWithAcknowledgement` already times out (30 s) on a worker whose port stays open but never acks, and that shape is almost always a blocked event loop — a native lock, a runaway synchronous call — which nothing inside the worker can report (harper-pro#788: a restarted node's single http worker went byte-silent while main kept serving `cluster_status`, and the app log only said "not acknowledged by worker thread(s) 2"). So each worker posts its Linux thread id (`readlink /proc/thread-self`) to main once at startup, before anything else runs on it, and the timeout branch reads that thread's kernel state from `/proc/self/task/<tid>`: state, `wchan`, the syscall number (the first token only — the rest of that file is argument registers and stack/instruction pointers), CPU ticks, and context-switch counts, plus two cross-platform signals main already has, `worker.performance.eventLoopUtilization()` and the age of the last 1 s resource report. It samples again a second later and logs the deltas: no CPU ticks, no context switches and `event loop active +1000ms` is "parked on a lock"; ticks climbing with state `R` is "spinning". It is deliberately main-thread-only and best-effort: `workers` and the tid live on the main thread's `Worker` objects, every `/proc` field is reported individually (a hardened container may deny `wchan`/`syscall` while `stat` stays readable), a follow-up sample whose `starttime` differs from the first is discarded (the tid may have been recycled), one diagnostic runs per worker with a 30 s cooldown so concurrent timeouts on the same worker don't multiply reads, and nothing here runs when acks arrive on time. It does not name the lock owner; that still needs a native stack from the next occurrence.
+
+## `chooseOperation` authorizes the invoked operation against the authenticated principal (`server/serverHelpers/serverUtilities.ts`)
+
+`verifyPerms` takes a request-shaped object and reads _both_ halves of the permission question off it: the principal from `hdb_user`, and the tables from `schema`/`database`/`table`/`records`. `chooseOperation` used to hand it `json.search_operation` — a caller-supplied field — which made both halves body-controlled. Fixing one half and not the other is not a fix: with an empty `search_operation` the table map is empty, and `hasPermissions` iterating nothing authorizes everything. Regression cover: `integrationTests/security/choose-operation-authz.test.ts`.
+
+Four rules hold this together, and all four are load-bearing:
+
+**The principal comes from authentication.** Authentication sets only the _top-level_ `hdb_user`, and `validateRequestBodyProperties` inspects only top-level keys, so a nested `hdb_user` must be overwritten, never backfilled `if (!...)`. All four callers of `chooseOperation` (`serverHandlers`, `serverUtilities.operation`, `registeredOperations` worker forwarding, MCP) set the top-level principal before dispatch, which is why this belongs here rather than only at the HTTP boundary.
+
+**`search_operation` is the permission subject only for the operations that consume it.** `dataLayer/export.ts` is its sole consumer (`export_local`, `export_to_s3`); for any other operation the substitution checks the nested tables while the handler runs against the top-level ones, so it is gated on the operation name. It must also be an object naming one of export's supported operations (`search_by_value`/`search_by_hash`/`search_by_conditions`/`sql`) — a primitive, `{}`, or an unsupported operation is a request-time 400, not a wrapped 500 or an asynchronously-failed job.
+
+**One check cannot authorize both the outer export and its nested query.** The outer op's own `verifyPerms` returns before any table check — `export_local`/`export_to_s3` are `requires_su`, and a role that lists the operation in `operations` is granted at gate 2 (an explicit listing of an SU-only operation is a deliberate grant). The job worker then runs `search_operation` through `searchByValue`/`searchByHash`/`searchByConditions`, none of which check permissions. So the outer invocation is authorized first, and then the nested search is authorized additively against its _real_ search handler (`getOperationFunction(search_operation)`) and the authenticated principal — otherwise a role granted `export_local` could export a table it holds no grant on. A nested `sql` search takes the SQL branch instead, but the same two-part shape holds: the outer export op runs through `verifyPerms` (so its `requires_su` gate, the `operations` allowlist, and the export token scope all apply, exactly as on the non-SQL path — SQL must not be a way around the requires_su gate), the statement must be a `SELECT` because export is read-only, and `checkASTPermissions` then covers the statement's tables. A direct `sql` call has no outer job op, so there the `operations` allowlist alone is the operation-invocation check.
+
+**`parsed_sql_object` is dispatch state, never client input.** The export worker re-reads it off the same caller-supplied nested object (`evaluateSQL`), and it carries `permissions_checked`, so a body-supplied one runs an AST no check ever saw. It is deleted from the nested object at dispatch, and stripped from the top-level object before this dispatch's own parse is assigned. Only the direct-SQL path consumes the top-level `parsed_sql_object`; a job re-parses off `search_operation`, so setting it for a job would be inert. The bypass/`apiOperation` decision is carried on async-context state (`getOperationAuthorizationState`), not on the request body, and `processAST` honors the denial `checkASTPermissions` computes — a `PermissionResponseObject` has no `length`, so the guard tests the object itself rather than `.length` (which always refused nothing).
+
+The SQL and job paths are additive rather than exclusive: `verifyPermsAST` validates only the statement's tables and attributes, never the `operations` allowlist or `requires_su`, and a table-free statement gives it nothing to validate — so the allowlist check and the AST check both run for a SQL-carrying request, and the nested-search check runs alongside the outer export check for a job.

integrationTests/apiTests/northwind.test.mjs

@@ -12477,7 +12477,21 @@ suite('Northwind operations', { skip: skipSuite }, (ctx) => {
 		                                    from northnwd.shippers`,
 					},
 				})
-				.expect(200);
+				.expect((r) =>
+					assert.equal(
+						r.body.error,
+						'This operation is not authorized due to role restrictions and/or invalid database items',
+						r.text
+					)
+				)
+				.expect((r) =>
+					assert.equal(
+						r.body.unauthorized_access[0],
+						"Operation 'export_local' is restricted to 'super_user' roles",
+						r.text
+					)
+				)
+				.expect(403);
 		});
 
 		test('Jobs Test Export To Local using SQL on RESTRICTED table as test_user', async () => {
@@ -12494,16 +12508,20 @@ suite('Northwind operations', { skip: skipSuite }, (ctx) => {
 		                                    from northnwd.suppliers`,
 					},
 				})
-				.expect((r) => {
+				.expect((r) =>
 					assert.equal(
 						r.body.error,
 						'This operation is not authorized due to role restrictions and/or invalid database items',
 						r.text
-					);
-					assert.equal(r.body.invalid_schema_items.length, 1, r.text);
-					assert.equal(r.body.invalid_schema_items[0], "Table 'northnwd.suppliers' does not exist", r.text);
-					assert.equal(r.body.unauthorized_access.length, 0, r.text);
-				})
+					)
+				)
+				.expect((r) =>
+					assert.equal(
+						r.body.unauthorized_access[0],
+						"Operation 'export_local' is restricted to 'super_user' roles",
+						r.text
+					)
+				)
 				.expect(403);
 		});
 
@@ -12521,7 +12539,21 @@ suite('Northwind operations', { skip: skipSuite }, (ctx) => {
 		                                    from northnwd.region`,
 					},
 				})
-				.expect(200);
+				.expect((r) =>
+					assert.equal(
+						r.body.error,
+						'This operation is not authorized due to role restrictions and/or invalid database items',
+						r.text
+					)
+				)
+				.expect((r) =>
+					assert.equal(
+						r.body.unauthorized_access[0],
+						"Operation 'export_local' is restricted to 'super_user' roles",
+						r.text
+					)
+				)
+				.expect(403);
 		});
 
 		test('Jobs Test Export To Local using NoSQL as test_user', async () => {