Add a Dependency-Version Matrix Axis to validate-task.yml for the Gates Stage #2334

Problem

validate-task.yml has no way to express a dependency-version axis in its pytest leg. Its only matrix input is python-versions, one leg per interpreter, and every leg installs the same locked dependency set through uv sync --all-groups --frozen.

homeassistant-purpleair cannot adopt the gates stage of the reusable-workflow rollout without that axis. docs/reusable-workflows.md "Rollout" records this only as a line under Stage 2 ("leaves the dependency-version axis open"), and no issue tracks it. Its gates adoption (ptr727/homeassistant-purpleair#365) and the remaining workflow findings of its hub audit (ptr727/homeassistant-purpleair#364) are both waiting on this.

The maintainer asked for this to be prioritized.

What the repo's matrix needs

Its carried test-release-task.yml builds the pytest matrix from a JSON file at runtime, one include entry per leg, and each leg overrides installed versions after the base install:

• homeassistant==<ha-version> and pytest-homeassistant-custom-component==<version>, per leg, for the minimum supported HA, the latest stable HA, and an optional latest beta.
• A library axis: one leg installs the client library's manifest minimum instead of the pinned version, and asserts which version is installed.
• Python is 3.14 on every leg. The repo uses requirements*.txt and carries no uv.lock.

The shape a leg needs looks like this (constructed example):

[
  { "label": "minimum",       "ha-version": "2025.1.0", "pytest-hacc-version": "0.13.200", "lib": "minimum" },
  { "label": "latest-stable", "ha-version": "2025.9.0", "pytest-hacc-version": "0.13.280", "lib": "pin" }
]

Possible shapes

1. A per-leg install hook. The task accepts a JSON include matrix and calls a caller-owned composite action (such as .github/actions/install-test-deps/action.yml) with the leg's entry, after the base install and before pytest. This matches the build-release-asset hook pattern that build-release-task.yml already uses.
2. A generic pip-overrides per leg. Each matrix entry carries a list of pkg==version overrides that the task installs. It's simpler, but it can't run the repo's "assert the installed minimum" check.
3. Declare the repo out of scope for the gates stage. It keeps its carried test task, and the audit stops reporting the validate interface finding for it.

Recommendation: option 1. It reuses an established hook contract and leaves the repo-specific install logic in the repo.