Document shared workflow inputs and the quoting rules for options inputs

[ericof]

Summary

Two related changes to how the shared workflows are documented and maintained.

The first fixes #404. Since #400 the *-options inputs are expanded by the shell from an environment variable rather than substituted into the script as literal text. Unquoted parameter expansion still splits on whitespace, but it does not perform quote removal — so quote characters inside the value survive into the argument. The value we documented as the recommended form:

zpretty-options: '--extend-exclude "/rss/(rss\.xml|search-rss)\.pt$"'

now reaches zpretty with the double quotes attached, matches nothing, and the deliberately excluded files get checked anyway.

Per the discussion on the issue this is documented rather than worked around in the workflow, so the injection surface that #400 closed stays closed. The reference now describes the real behaviour, marks the two affected inputs, and shows the unquoted form.

The second closes a Dependabot blind spot found while reviewing the same files.

Documentation

docs/sources/reference/shared-workflows.md grew from 281 to ~530 lines:

• A new Passing values to string inputs section covering word splitting, quote retention and glob expansion, with the correct and broken forms side by side. It also states that an argument containing whitespace cannot currently be passed at all.
• Input tables for all fifteen reusable workflows. Only backend-lint had one.
• Five reusable workflows that were missing from the reference entirely, now grouped as tox Workflows: coverage, circular, dependencies, qa, release_ready.
• Corrected composite action tables. Between them they omitted five inputs — setup_backend_uv was missing plone-version and working-directory, and setup_frontend documented one of its four inputs.
• Corrected container registry secret names. They were documented as registry-username / registry-password; the workflows actually declare username / password, so the documented example could not have worked.
• container-image-build and container-image-push distinguished by the registry-backed build cache they share.
• A Permissions preamble recording that the reusable workflows declare no permissions: of their own, plus a table for frontend-storybook showing that deploy: true needs contents: write from the caller. Its deploy step also only runs on refs/heads/main, which was undocumented.

Dependabot

For the github-actions ecosystem, directory: "/" covers .github/workflows and a root-level action.yml. Our composite actions live at .github/actions/<name>/action.yml, which is neither, so nothing has ever updated their dependencies.

The dependency graph confirms it: actions/setup-node does not appear at all — it exists only inside setup_frontend — and astral-sh/setup-uv appears only at the versions used by the workflows, never at the v8.2.0 pinned inside the composite actions. Every commit touching .github/actions since it was created has been a manual bump.

Switched to the directories key so those directories are scanned too.

Please sanity-check the glob. I could not verify that /.github/actions/* resolves for this ecosystem — globbing is documented as a directories feature, and what / means is documented separately per ecosystem, but the docs do not say the two compose. If it matches nothing we get no coverage and no error. After merge, actions/setup-node appearing in the dependency graph is the signal that it worked; if it does not, the fallback is listing the three action directories explicitly.

Out of scope

astral-sh/setup-uv is stale at v7.5.0 in six workflows and v7 in docs.yml, while v8 has been out since March. This is not the scope problem above — the dependency graph shows Dependabot sees it and skips it, and it has never opened a PR for it. Likely an ignore condition or a failing update job; both are visible from Insights → Dependency graph → Dependabot. Worth a separate issue.

Verification

make docs builds clean. The only warning is pre-existing and unrelated (how-to/setup-to-pyproject is not in a toctree). All new cross-references resolve.

Closes #404