Match ark boarding addresses to loop static address format

Nobody has claimed this yet.

## Context and goal

Ark boarding addresses and Loop static addresses solve nearly the same pre-spend custody problem, but today they use different taproot shapes. Ark boarding currently uses an Ark-style policy tree with a collaborative tapleaf and a CSV timeout leaf, while Loop static addresses use a MuSig2 2-of-2 taproot key path plus a CSV timeout leaf.

Make new opt-in Ark boarding addresses so their output script matches the Loop static address format for the same client key, operator/server key, and CSV delay.

It seems very beneficial that at a time of making a deposit to a static address the client is free to choose:
- do a static loop-in
- use it as Ark boarding address deposit
- withdraw cooperatively
- unilateral withdrawal after CSV timeout
- (future) maybe use in Pool also?

## Scope

This issue is only about pre-batch boarding UTXOs. It must not change Ark VTXOs, vHTLCs, OOR outputs, connector outputs, batch outputs, or existing already-created boarding addresses.

The existing Ark boarding format must remain supported for the foreseeable future. Static-format boarding should initially be opt-in and enabled only when both client and server advertise/configure support.

No files or tests are named. Trace the existing Ark boarding-address and Loop static-address implementations, then review how client and server capabilities or configuration are advertised; done means opt-in boarding outputs match the Loop format while legacy boarding and all other output types remain unchanged.

Written by the indexing model from the issue text.