Migrate MediaTools to the plan-job publisher so its registry entry records reality #1478

Found while retiring the publish-on-merge release trigger for #1467. That retirement is correct and is not blocked by this, but it leaves one repository whose behavior the vocabulary can no longer describe, and the fix is the repository rather than the vocabulary.

MediaTools publishes on a human merge

registry/repos.json records MediaTools as releaseTrigger: two-phase. Its publisher does not behave that way:

• on: push: branches: [main, develop], filtered to MediaTools/**, version.json, Directory.Build.props, Directory.Packages.props.
• No plan job, and no reference to publish-plan-task.yml anywhere in the file.
• The publish gate is if: ${{ github.event_name == 'push' || github.ref_name == 'main' || github.ref_name == 'develop' }}, which carries no actor condition at all.

So an ordinary human promotion merge to main that touches a shipped path cuts a release. WORKFLOW.md D4.1 and GOVERNANCE.md "Release Model" both state the opposite as a fleet guarantee ("a human merge never auto-publishes"), and GOVERNANCE.md "Repository Onboarding and Conformance" requires the registry to record reality, so the entry is false today whichever way the value goes.

The resolution that worked for aiopurpleair applies here: adopt the plan-job publisher (ptr727/aiopurpleair#92), after which two-phase becomes true rather than being made true by relabelling. spec/files.json's interface contract for .github/workflows/publish-release.yml already requires plan, validate, publish with plan calling publish-plan-task.yml, so MediaTools does not satisfy that contract either and an audit of it reports the same finding.

KiCadLibrary is the latent case

KiCadLibrary has the same shape behind an opt-in: on: push: branches: [ main, develop ], no plan job, and a setup job that sets publish=true for a push only when the repository variable PUBLISH_ON_MERGE is 'true'. That variable is currently unset (the repository has no Actions variables at all), so it behaves as two-phase today and its registry entry is accurate. Setting one variable makes it a publish-on-merge repository with no valid value to record it as, so it belongs in the same migration rather than in a separate one later.

PUBLISH_ON_MERGE appears nowhere in the hub's canonical text. It is that repository's own mechanism, not a fleet one.

Why this is not an argument for keeping the value

The enum described an intent the fleet's own contract forbids, and the task it pointed at (publish-plan-task.yml) has no path that serves it, which is what #1467 opened on. Recording MediaTools as publish-on-merge would make the registry accurate and leave the repository outside D4.1 with a label that says that is fine. Migrating it makes the repository conformant and the registry accurate at the same time.

Not covered here

The merge-and-release skill's step 5 assumes the dispatch it issues is what ships the release. That holds for a publisher carrying the plan job and does not hold for MediaTools today, where the promotion merge can publish before the dispatch runs. Two attempts to state that exception in the skill were withdrawn, because every formulation of the test was defeated by one of these two repositories (a job named setup rather than plan, and a paths filter under which a merge may start no run at all). Once both repositories are migrated the exception disappears and the skill's plain instruction is correct again, which is the other reason to fix the repositories rather than the prose.