Skip registry-derive in publish-docs for non-provider distributions

[potiuk]

Summary

The "Derive registry trigger inputs" step in
publish-docs-to-s3.yml runs
python3 dev/registry/derive_wave_providers.py unconditionally in
the Build Info job. The downstream update-registry job only runs
when registry-providers != '' or registry-full-build == 'true' —
so for non-provider distributions (apache-airflow,
apache-airflow-ctl, apache-airflow-task-sdk, helm-chart,
docker-stack) the script's output isn't consumed and the script
invocation is a no-op.

This PR skips the script invocation for those distributions:

• Both registry-providers= and registry-full-build=false are
  set so the update-registry job skips downstream as expected.
• Release tags cut before Reigstry: Fix wave-release auto-trigger meta-token expansion #66100 (when the script was added) can
  publish docs again without the workflow tripping on the missing
  file. Surfaced while publishing docs for airflow-ctl/0.1.4
  (cut from 0.1.4rc3 on 2026-04-22).

The non-provider list is kept in sync with NON_PROVIDER_TOKENS in
dev/registry/derive_wave_providers.py.

closes: #66436

Test plan

• breeze workflow-run publish-docs --ref airflow-ctl/0.1.4 --workflow-branch airflow-ctl/0.1.4 apache-airflow-ctl succeeded with the workflow YAML at the tag (workaround that exposed the issue): https://github.com/apache/airflow/actions/runs/25393124890
• After this PR lands: re-run publish-docs for airflow-ctl/0.1.4 against the workflow on main to verify the skip path works end-to-end with the new YAML.
• After this PR lands: re-run publish-docs for a wave-tag ref (e.g. providers/2026-MM-DD) to verify the provider path still invokes the script.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.7)

Generated-by: Claude Code (Opus 4.7) following the guidelines

[github-actions]

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 73f2735 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.