adapter: add internal subscribes for reading a mutation's input

[aljoscha]

Motivation

Part 5 of 7 in a stack that moves DELETE, UPDATE and INSERT ... SELECT
off the coordinator onto the session task, using optimistic concurrency
control. Design doc:
20260210_incremental_occ_read_then_write.md
(lands in part 6).

A read-then-write sequenced off the coordinator needs to observe its
selection as it changes, and stream the mutation's diffs rather than peek
every matched row and recompute them. A subscribe already does exactly that.
What it must not do is appear to be one.

Closes SQL-591

Description

An internal subscribe writes no mz_subscriptions row and does not move the
active-subscribes gauge, so introspection keeps showing only the subscribes a
user started.

Creation is fallible, and that is the substantive difference from the
coordinator's own read-then-write path. Here the dataflow is optimized
against a catalog snapshot on the session task and shipped when the
coordinator handles the message, and a DROP of a dependency can land in
that window. The coordinator optimizes and ships in one turn of its loop and
has no such window, which is why it can treat creation as infallible. So this
returns ConcurrentDependencyDrop for the session to report, the same answer
the frontend peek path already gives. Shipping precedes registering the sink,
so a failure has nothing to unwind, which costs no concurrency because an
internal subscribe's registration writes no introspection row.

Read holds are passed through the stages rather than kept in the
connection-keyed txn_read_holds map, so concurrent operations on one
connection cannot interfere with each other's holds, and they are released
only once the dataflow is installed.

Temporary scaffolding. Nothing calls these handlers until part 6, so a
dead_code allowance keeps the crate warning-free. Part 6 removes it in the
same commit that adds the callers.

Verification

No caller yet, so this part is carried by the tests in parts 6 and 7. Part 6
includes a test that a dependency dropped underneath a running read-then-write
produces a retryable error rather than a coordinator panic.

[linear-code]

SQL-591