fix(testnets): give the cloud_engine controller usable init args

[pietrodimarco-dfinity]

The engine controller is installed alongside the NNS, and cloud_engine left its init args None — so both of the canister's own defaults applied, and both are mainnet-shaped:

default	value	on a testnet
DEFAULT_AUTHORIZED_CALLER	bct5z-vccu4-…-fqe (mainnet backend principal)	no local canister may call the controller
DEFAULT_INITIAL_DKG_SUBNET_ID	fuqsr-in2lc-…-nae (a mainnet subnet)	subnet does not exist, so engine subnets cannot be bootstrapped

Net effect: engine creation cannot work on any cloud_engine testnet. Confirmed against the live testnet, where getEngineController() resolves and the controller is installed, but its authorized caller is the mainnet principal rather than the consumer's engine canister.

Changes

• nns_dapp: add nns_dapp_customizations_with_engine_controller(authorized_caller, initial_dkg_subnet_id).
• cloud_engine: pass the engine canister (5s2ji-faaaa-aaaaa-qaaaq-cai, the whale reservation) as the authorized caller, and this testnet's own NNS subnet — read from the topology, not hardcoded — as the DKG source.

5s2ji is hardcoded because the controller is installed before the reservations are created, and the append-only reservation order fixes the id; the file already documents that contract.

The helper lives in nns_dapp rather than in the testnet because nns_dapp already depends on ic-nns-test-utils, where EngineControllerInitArgs is declared. Adding that dependency to rs/tests/testnets would have meant touching both Cargo.toml and BUILD.bazel — the mismatch that made #10928 red earlier today.

Verification

cargo check --locked -p testnets -p nns_dapp --all-targets passes, and rustfmt --edition 2024 is clean. Not yet exercised end to end: it takes effect on the next testnet build, and the proof will be an engine creation getting past changeSubnetMembership.

🤖 Generated with Claude Code

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

[daniel-wong-dfinity-org-twin]

Not sure what the "whale" canister is. Sounds like an informal name only known to a small clique.

[daniel-wong-dfinity-org-twin]

This sounds like the type of extra stuff that Claude would say.

The main thing that comments explain is what the code does. Comments can go into why of the how things are done (e.g. here), but I would only do that if someone would look at this, and be like, "wtf? I'm going to change this to do it the 'obvious' way". But in this case, I don't think there is necessary an "obvious" alternative that someone would just spontaneously "correct" this to, since, as this comment says, it would require editing the build files (i.e. Cargo.toml and BUILD.bazel). Even if someone does want to jump through those hoops, I do not see what the harm would be, why we should try to stop them with this comment. If they did that, then, rather than indirectly depending on other libraries, this would just depend on them DIRECTLY. That is arguably a good thing. E.g. at Google, we used to say "Depend on what you use" (and I don't see how you can really find fault with that!). In any case, not touching the build files does not actually change the "transative closure" of what you depend on. The exact same changes result in the exact same build cache invalidations.