fix: initialize the servers before publishing their addresses (7.0.1:1)

[MattDHill]

On install, the SMP and XFTP addresses were published as:

smp://undefined:null@relay.example:5223

Well-formed enough for a client to accept and store, and impossible to authenticate against.

Cause: init order, not a race

export const init = sdk.setupInit(
  restoreInit,
  versionGraph,
  setInterfaces,   // 3rd — reads the fingerprint and the password
  actions,
  initServers,     // 5th — runs `smp-server init`, which writes them
  watchTorProxy,
  setDependencies,
)

setupInit runs handlers sequentially, so on a fresh install setInterfaces executed before smp-server init had ever run. smp-configs is empty at that point — no fingerprint file, no smp-server.ini to read AUTH.create_password from — and both empty reads were interpolated straight into username.

The pass does re-run on its own, since both reads are .const() and setupInit gives each handler a constRetry. But the window it corrects is two subcontainer spawns doing keypair generation wide, and it recurs on every reinstall — with a fresh CA on the other side.

Fix

initServers moves above setInterfaces. It's a seed step: it reads no host or interface state, only volumes and file models (smpMounts/xftpMounts are plain volume mounts), while setInterfaces is the thing that consumes what it writes. The dependency only ever ran one way. This matches how lnd and cln — the other two packages whose setInterfaces reads generated files — order their own seed steps ahead of it.

That's the whole change. The reads are left unguarded, because after the reorder nothing can reach them empty: execFail throws if smp-server init fails, the non-install path already throws when the ini carries no create_password, and setupInit awaits each handler without catching — so either failure aborts init rather than arriving at setInterfaces with nothing to read.

(lnd and cln do guard their equivalent reads, but for a condition this package doesn't have: their credentials are deleted and re-minted at runtime by rune revocation and macaroon rotation, so both pass a custom eq to ignore the gap. Nothing here ever removes the fingerprint.)

Bumped to 7.0.1:1; wrapper-only, no migration.

How it surfaced

simplex-websocket-bridge-startos resolves this interface as its Local relay and picked up the undefined:null form while following a reinstalled server to its new address. It landed a fingerprint-shape guard on its side (Start9-Community/simplex-websocket-bridge-startos#14) — worth keeping regardless, since a consumer shouldn't trust a relay URI's shape — but the malformed value originated here.

Related: Start9Labs/start-technologies#3861 fixes the SDK-side reason the bridge stopped noticing address changes at all.