publishing-automation.md documents audioif's pre-split three-call chain and calls publishing-v6 current

[bdbarnett]

Noticed by release-pilot while cutting audioif v0.2.0 (2026-09-03, run 33805941801), the first release after the audioif→audiocomponents split.

docs/publishing-automation.md is stale in two independent ways:

1. Around lines 229–237 it documents audioif's chain as three reusable calls — native-and-wasm plus two pure-python component builds with mip-profile: audioinstruments,audioeffects. Since audioif e18eeee the repo has ONE publish job (native-and-wasm, expected-wheel-count: 21, no mip-profile); the two component distributions and both MIP entries publish from PyDevices/audiocomponents (its publish-release-packages.yml: gates → publish-audioinstruments carrying the comma-separated profile, plus publish-audioeffects).
2. Line ~31 says publishing-v6 is current. The live coordinator every consumer pins is publishing-v8 (prepare/tag reusables are still called at v6 by consumers, which is a third thing the doc should say plainly).

Someone reading the runbook before the workflow file gets the wrong chain twice. Fix is a docs pass against the actual files; the release-health row for pydevices-audioif 0.2.0 (TestPyPI OK, assets OK, MIP --) is what the doc should now describe as normal for this repo.

[bdbarnett]

One more thing the runbook should say, learned on audiocomponents' first release tonight: when a MIP-published package moves repositories, the lockfile's repository key acts as a guard — reusable-synchronize-mip-package refuses a dispatch whose source repository differs (profile 'audioinstruments' requires PyDevices/audioif, not PyDevices/audiocomponents), while the releasing repo's request-mip-publication job reports success, so the failure only shows in mip's own runs. The order is: tag in the new repository → repoint repository/ref in pydevices-lock.json (mip f94ef5e9 tonight) → re-run the failed mip runs. The runbook's lockfile section should name that as the move procedure.