Problem

oasis rofl machine show prints the TXT record users must add to verify a custom proxy domain. Since #696 the token was derived from the provider's scheduler app ID instead of the deployed app ID:

// fetched with out.Provider.SchedulerApp, to read the proxy domain metadata
out.Replica, _ = conn.Runtime(...).ROFL.AppInstance(ctx, ..., out.Provider.SchedulerApp, pk)
...
prettyPrintMachinePorts(mCfg.ExtraCfg, out.Replica.App, out.Machine, proxyDomain)

The scheduler derives it from deployment.app_id, so the record we tell users to add can never verify. The failure is opaque: the scheduler logs TXT record not found (a token mismatch, not a missing record), never installs the SNI mapping, and the app's ACME TLS-ALPN-01 challenge fails with unexpected order status: Invalid until Let's Encrypt's authorization-failure limit kicks in.

Why it surfaced only now

#696 swapped in out.Replica.App to avoid a nil dereference when the machine has no deployment. That produced wrong tokens, but nothing failed visibly, because the scheduler's own derivation finalized TupleHash into a zero-length buffer and returned "" for every input — which reduced verification to contains("oasis-rofl-verification="), a prefix match that accepted any such record. rofl-scheduler v0.9.0 is the first release with the fixed derivation, so it is the first release that actually compares tokens.

Fix

Derive from insDsc.Deployment.AppID again, keeping the nil handling #696 was after: when nothing is deployed we now print a short notice instead of a token.

Impact

Anyone who added a TXT record based on output from a CLI containing #696 has an incorrect record and must re-run oasis rofl machine show and update DNS. Domains that appeared to verify under scheduler ≤0.8.0 were never genuinely verified.

Testing

gofmt, go vet, go test ./... clean. Verified end to end on a Testnet machine: replacing the TXT record with the correctly derived token made the scheduler log domain verification successful, and the certificate was issued.