What

Replaces the SEA backend's neutral, synthesized operation status with the real fields the napi kernel handle exposes on a terminal statement. Before this change, SeaOperationLifecycle.synthesizeFinishedStatus() returned a fixed { state: Succeeded, hasResultSet: true } with a comment that numModifiedRows / displayMessage / etc. were "deferred to M1", so getOperationStatus() on SEA reported nothing beyond the state. The napi Statement already exposes numModifiedRows() / displayMessage() / diagnosticInfo() / errorDetailsJson(); the JS side now reads and surfaces them.

Changes

• lib/contracts/OperationStatus.ts — the backend-neutral OperationStatus carries the four rich fields (numModifiedRows, displayMessage, diagnosticInfo, errorDetailsJson).
• lib/sea/SeaOperationBackend.ts — new readRichStatusFields() reads the accessors off the terminal sync Statement (the metadata path, and the sync runAsync:false path once result() has resolved). Null-safe: the async submit path never produces a terminal Statement (the AsyncStatement / AsyncResultHandle don't expose these accessors), and older bindings that predate the accessors both degrade to all-null rather than throwing. Wired into status() and the sync/cancellable completion tick. A failed individual accessor read is swallowed to null so a successful operation's status query never turns into a throw.
• lib/sea/SeaOperationLifecycle.ts — seaFinished() merges the rich fields into the synthesized completion tick via a lazy thunk, so finished({ callback }) consumers see the same surface as a subsequent getOperationStatus() call.
• lib/thrift-backend/wireSynthesis.ts — synthesizeThriftStatus() maps the rich fields into TGetOperationStatusResp (numModifiedRows re-boxed as a node-int64 Int64 to match the Thrift deserializer's wire shape; null → undefined so the synthesized response matches the Thrift path, where an absent field is simply not set).

numModifiedRows note

numModifiedRows is currently null on SEA, by server behavior: the SEA /statements REST API does not populate num_modified_rows in the status object — verified live against pecotesting across dispositions/wait_timeout/user-agent. Instead, the server delivers a DML's modified-row count as result-set data (the result has columns num_affected_rows / num_inserted_rows). The kernel's Statement.numModifiedRows() reads StatementStatus.num_modified_rows, which the server never sets, so it returns null.

A companion kernel change (made in the single kernel PR) derives num_modified_rows from the DML result row. Once that lands, this driver wiring surfaces numModifiedRows with no further driver change — the title lists it as part of the operation-status surface this PR completes, not a value demonstrable today.

The other three fields (displayMessage, diagnosticInfo, errorDetailsJson) have legitimate server population paths (terminal-error states; admin-enabled workspaces for errorDetailsJson) and are surfaced by this wiring where the server provides them.

Testing

• Unit: 101 passing across tests/unit/sea/operation-lifecycle.test.ts, tests/unit/sea/SeaOperationBackend.test.ts, tests/unit/sea/execution.test.ts, and tests/unit/thrift-backend/wireSynthesis.test.ts.
• Live (pecotesting, useSEA: true): CREATE TABLE + INSERT INTO ... VALUES (1),(2),(3) + SELECT 1 all execute and report status cleanly through the full chain; getOperationStatus() returns the rich-field shape (values reflect exactly what the kernel returns — numModifiedRows null today per the server note above), and the table is dropped after.

This pull request and its description were written by Isaac.