fix(publish): underscore image names + existing_tag recovery dispatch

[sebasnallar]

What happened with v1.16.1

Run 33766821675 is a failure, not green: scopes/containers pushed and registered fine, but scheduled-task and containers-datadog never pushed anywhere — their ECR repositories don't exist (verified against the registry API: neither the hyphen nor the underscore names exist), and ECR never creates repositories on push. So there is nothing wrongly-named to clean up; the fix is free to pick the right names.

Changes

• scopes/scheduled-task → scopes/scheduled_task and scopes/containers-datadog → scopes/containers_datadog (underscores, matching the source directories) in image_name, the np artifact create --repository, and the release table. scopes/containers untouched.
• workflow_dispatch with existing_tag: a tag push runs the workflow at the tagged commit, so this fix can never reach v1.16.1 via re-run or tag re-push — the dispatch path runs the current workflow for an existing tag. Every github.ref_name use falls back through inputs.existing_tag ||.
• CLI install: alpha-packages channel → released 2.10.0.

To recover v1.16.1 (in order)

1. Create the two ECR Public repositories (needs AWS creds with ecr-public perms):

   aws ecr-public create-repository --repository-name scopes/scheduled_task --region us-east-1
   aws ecr-public create-repository --repository-name scopes/containers_datadog --region us-east-1

2. Merge this PR.
3. gh workflow run publish-images.yml --repo nullplatform/scopes -f existing_tag=v1.16.1

The re-run re-registers the containers artifact identically (idempotent upsert) and the release upsert is digest-guarded, so nothing duplicates.

🤖 Generated with Claude Code

[sebasnallar]

Updated: the three build calls now pass ref: ${{ inputs.existing_tag || '' }} so the recovery dispatch builds the tag's commit, not main's head — depends on actions-nullplatform#100 (merge that first; until then the extra input is ignored harmlessly... actually no: an unknown input to a reusable workflow is a startup error, so #100 must land before this runs).