fix: don't leak server-side state when a future is cancelled - #1374

StatementInner::drop and Portal's Inner::drop build the same Close
message with only the target byte differing. Pull it into one place so
there is a single definition of how a Close is framed - close, sync, and
send as one request - rather than two copies that can drift apart.

Pure refactor, no behaviour change. The early return for unnamed
statements stays where it was, in StatementInner::drop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Own each server-side object from the moment it might exist, rather than
from the moment the value that owns it is constructed.

prepare() and bind() both allocate a name and put the message that
creates the object on the wire before awaiting anything, but Statement
and Portal - whose Drop impls are the only emitters of Close - are built
only after the last response has been read. Dropping the future in
between, or returning early via `?`, stranded the object with nothing
left that knows its name. _savepoint() has the same shape: it sends
SAVEPOINT and builds the nested Transaction that owns the cleanup only
afterwards.

Add DropGuard, a general arm/disarm guard that runs a closure unless
disarmed, and use it at all three sites: armed right after the request
is sent, disarmed once the owning value takes over.

For prepare() and bind(), arming before the creating message is
confirmed is deliberate. Waiting for confirmation would miss the common
case, cancelled after the request went out but before any response came
back. It is safe because closing a name that does not exist is
explicitly not an error in the protocol, so the cost is at most one
redundant Close on a failed prepare. Ordering is safe too, since the
Close travels the same request channel as the message that created the
object and the connection processes requests FIFO.

Because the guard covers `?` exits as well as cancellation, and because
each recursive prepare arms its own, this also fixes the typeinfo
lookups that prepare() performs for non-builtin types.

_savepoint() needs the opposite error policy: RELEASE against a
savepoint that does not exist is an error and would poison the
enclosing transaction, so a spurious cleanup is not free the way a
spurious Close is, and the guard disarms on failure rather than
propagating first. Arming before the send is still safe because no
suspension point separates constructing the guard from the send inside
batch_execute - if the guard is ever dropped armed then the SAVEPOINT
was queued and will run. RELEASE rather than ROLLBACK TO, since nothing
ran inside the savepoint and ROLLBACK TO would leave it defined.

All tests added two commits ago now pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit added a general arm/disarm guard. TransactionBuilder
::start already hand-rolls the same thing as a local RollbackIfNotDone
struct, so fold it in.

Behaviour is unchanged, including the error policy: an error from
batch_execute still propagates with the guard armed, so a failed START
TRANSACTION is still followed by a fire-and-forget ROLLBACK.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>