fix: resolve dependency addresses from the bridge address, not assignedPort

[MattDHill]

Why

This package resolved its dependencies' addresses by reading bindings[<port>].net.assignedPort. That field is raw metadata, and which port field is populated depends on how the dependency bound the port — a binding with addSsl frees assignedPort entirely and carries only assignedSslPort.

LND hit exactly this when it moved REST behind the OS reverse proxy (Start9Labs/lnd-startos#171): every dependent silently resolved null.

What changed

Adopts sdk.host.getBridgeAddress, added in start-sdk 2.0.9 (Start9Labs/start-technologies#3560, #3561), and deletes the local copy of the helper this package was carrying — one of 44 near-identical copies across the fleet.

The helper resolves the binding's own derived bridge address, which is correct whether the dependency terminates its own TLS or hands the port to the OS proxy. It is computed per binding rather than per exported interface, so it also resolves bridge-only bindings such as tor's SOCKS proxy.

ssl: is passed only where the target binding publishes two bridge addresses — protocol: 'http'/'ws', or secure: null with addSsl. bitcoind's RPC is the clearest case (10.0.3.1:8332 ssl=false alongside 10.0.3.1:54404 ssl=true), so an undiscriminated lookup there is order-dependent. Where a binding publishes one address no discriminator is passed — pinning one would assert a fact about how the dependency binds, the coupling this change removes.

On the lockfile diff

Larger than expected, and expected to stay that way for now. This package pins git dependencies that track #next branches, which still resolve start-sdk 2.0.7, so npm nests a second SDK copy rather than hoisting one. It collapses once those next branches carry 2.0.9. The lockfile has to be committed regardless — s9pk.mk and the reusable CI both run npm ci, which fails on a lockfile out of sync with package.json. Functionally inert: the git deps are imported for types, and the s9pk build tree-shakes.

Verification

tsc and prettier clean against the published start-sdk 2.0.9. The resolution logic was verified live on a StartOS 0.4.0-beta.10 box: with LND on addSsl, net.assignedPort reads null while the binding's bridge entry resolves to 10.0.3.1:8080; LNbits connected through it (✔️ Backend LndRestWallet connected), and Fulcrum picked bitcoind's plaintext :8332 leg over the TLS :54404 one.

Not exercised against a running instance of this service — compile-checked only.

Test plan

1. Install this build alongside its dependencies.
2. Confirm it connects to each one and its health checks go green.
3. Restart a dependency and confirm the address re-resolves without a restart loop — .const() should settle on one value and stay there.

🤖 Generated with Claude Code

[helix-nine]

Reviewed: resolves dependency addresses via sdk.host.getBridgeAddress rather than the raw net.assignedPort / assignedSslPort fields, which are only populated depending on how the dependency bound the port. Verified live on a 0.4.0-beta.10 box across lnd, cln, fulcrum and lnbits.