Add completion-driven direct dispatch behind spt.dispatch.direct

[mikehorgan-dell]

Summary

Completion-driven direct dispatch for the built-in Netty drivers, gated by the JVM property spt.dispatch.direct (default off; behaviour with the property unset is unchanged).

When a request completes successfully on an event-loop thread, NettyStorageDriverBase.complete() keeps the concurrency permit and the channel, publishes the completed operation, and — under the existing admission lock — polls the next plain operation from the driver queue, marks it dispatched, and sends it on the same channel from the same thread. This removes the per-operation dispatcher hand-off and the second event-loop wake that the dispatcher's foreign-thread write used to cause. The dispatcher remains the path for composite/MPU work, child operations, NOOP, the batch submit(List) API, drivers that opt out, and any completion that refuses the direct path.

• CoopStorageDriverBase: pollForDirectDispatch(), dispatcherBacklog(), directDispatchEnabled(), supportsDirectDispatch() capability (default false), handleCompleted(op, wakeDispatcher). No existing signature changed.
• OperationDispatchTask: with direct dispatch on, drains only what it can submit now, publishes its backlog before parking so completions yield to buffered work, and parks instead of spinning when queued work has no capacity.
• NettyStorageDriverBase: direct path in complete(), capability true.
• S3RdmaStorageDriver and S3TablesStorageDriver opt out: their submit() does per-op preparation (RDMA buffer/context; control-plane modes) that sendRequest alone does not perform. NIO/fs and third-party cooperative extensions are unaffected by the property.

The default stays off. Flipping it is tracked separately: capability audit done; integrated canaries (TLS, streamed payloads, cancellation, failure injection, soak, distributed real-target run) and READ-at-concurrency screens still to run.