fix(k8s): register the update-scope action so scope edits run the update workflow

[pablovilas]

What

Editing a k8s scope did nothing on the cluster. The provider ships k8s/scope/workflows/update.yaml (the create workflow minus domain generation, traced as Update scope / job k8s-scope-update) and service/scope/entrypoint routes an action of type update to it — but k8s/specs/actions/ never declared such an action, and available_actions in the service spec did not list it.

The orchestrator treats update as an optional action (OPTIONAL_ACTIONS in main-scope-workflow-manager/services/custom/custom_scope_service.js): finding no action of type update on the service it adds an INFO message to the scope and moves it straight to active. So an edit was "done" immediately, the cluster kept the old ingress/IAM/DNS, and the scope page had no operation to show — while the 1.16.0 changelog promises step-by-step progress "when a scope is created, updated or deleted".

How

• k8s/specs/actions/update-scope.json.tpl — same shape as create-scope, type: "update", retryable: false, parameters { scope_id } (what the orchestrator sends: triggerAction(service.id, spec.id, { scope_id })).
• k8s/specs/service-spec.json.tpl — update-scope added to available_actions.
• README and CHANGELOG ([Unreleased], user-facing, with the one-time registration for existing providers).

Nothing else changes: ./configure registers every specs/actions/*.tpl, and the orchestrator already handles the UPDATING cycle for a repeatable update action (it always triggers a fresh action and moves the scope to active when it succeeds).

Rollout

• New providers: ./configure picks the action up.
• Existing providers: the service specification already exists, so the action must be registered once against it:

  SERVICE_SPECIFICATION_ID=<id> gomplate --file k8s/specs/actions/update-scope.json.tpl \
    | np service specification action specification create --serviceSpecificationId <id> --body "$(cat)"

  Until then, behaviour is exactly as today (update skipped, scope active).

Please validate before releasing

This enables a code path that has never run against a real cluster from the platform: the update workflow exists and is unit-tested (service/scope/tests/entrypoint.bats covers the update-scope routing), but no service has ever had the action to trigger it. Register it on a stage provider first and edit a throwaway scope: expect the IAM role / service account / ingress / DNS steps to re-apply idempotently and the scope page to show Update scope with its steps.

Same gap, not touched here: scheduled_task also ships a scope/workflows/update.yaml override and has no update-scope spec either.

Tests

bats service/scope/tests/entrypoint.bats — 7 passing. Both templates render to valid JSON (jq) with type: update / update-scope listed.