feat: allow the engine controller to call update_subnet

[pietrodimarco-dfinity]

What

Relax update_subnet's authorization in the registry canister from governance-only to governance-or-engine-controller (the same gate already used by create_subnet / delete_subnet), so the engine controller canister can update the subnets it manages — e.g. to halt or resume them — by calling update_subnet directly, without an NNS proposal.

Diff

One line in rs/registry/canister/canister/canister.rs:

-    check_caller_is_governance_and_log("update_subnet");
+    check_caller_is_governance_or_engine_controller_and_log("update_subnet");

Tests

• The existing update_subnet authorization tests still hold: anonymous callers and non-authorized canisters are rejected, governance is accepted — the gate is only widened to also allow the engine controller.
• The end-to-end engine-controller → update_subnet path is covered by the PocketIC integration test in the stacked engine-controller PR (feat: let the engine controller update subnets via update_subnet #10434), which passed locally along with the candid test.

[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