fix(release): correctly generate and apply engine-controller upgrade proposals

[pietrodimarco-dfinity]

Two fixes so the NNS release tooling handles the engine-controller canister
correctly end-to-end. (Follow-up to #10399, which added partial support.)

1. Map engine-controller to its source location (functions.sh)

get_nns_canister_code_location had no code_location__engine_controller
entry, so generating an engine-controller upgrade proposal aborted under
set -u with an unbound-variable error on the ${!n} indirect lookup:

.../lib/functions.sh: line 163: !n: unbound variable

Added the mapping to rs/engine_controller so proposal-text generation (and
the unreleased_changelog.md lookup) resolves.

2. Pass () upgrade arg for engine-controller (release-runscript)

The canister's post_upgrade takes Option<EngineControllerInitArgs>:

#[post_upgrade]
fn post_upgrade(args: Option<EngineControllerInitArgs>) { apply_init_args(args); }

An upgrade proposal generated without an argument carries an empty install
arg, which Candid cannot decode (no DIDL header), so post_upgrade traps and
the upgrade rolls back. Because NNS root's change_nns_canister is
fire-and-forget (it spawns stop→install→start and replies immediately), the
proposal is still recorded as Executed with no failure_reason — the
canister is silently never upgraded.

Generate engine-controller proposals with an explicit () arg (the same
mechanism already used for cycles-minting) so post_upgrade decodes to
None and the upgrade applies.

Verification

Reproduced on a testnet:

• No-arg upgrade proposal → status = Executed, but module hash and embedded
  git_commit_id unchanged (silent no-op).
• Identical upgrade with explicit () arg → module hash and git_commit_id
  updated to the target commit.
• cargo check -p release-runscript passes.

[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

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 6494992.

Security Overview

• 🔎 Scanned files: 2 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/f975f1a5-0a47-4a3b-b7f0-a55609e90390?scanId=7993199e-ac6e-44d5-959f-12eba7df4139&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Refactor	► rs/nervous_system/tools/release-runscript/src/main.rs     Handle upgrade arguments for cycles-minting and engine-controller canisters
Enhancement	► rs/nervous_system/tools/release/lib/functions.sh     Add code location for engine-controller canister

Done