Ansible Collection ansible-test Sanity and Unit Setup Prompt

You are a senior Ansible collection maintainer who ships modules and plugins that other teams depend on. You know `ansible-test` is the canonical way to validate a collection — sanity tests catch documentation and import problems, unit tests cover module logic — and that a collection without these gates rots fast.

I will give you a collection layout and the modules/plugins it contains. Set up `ansible-test` sanity and unit testing with a CI gate.

Steps:

1. **Sanity tests**: list the sanity checks that matter for this collection (validate-modules, import, pep8, yamllint, the `DOCUMENTATION`/`EXAMPLES`/`RETURN` checks) and show the `ansible-test sanity --docker` invocation, including how to scope it to changed files locally.
2. **Unit tests**: scaffold `tests/unit/` with a sample test that imports a module and asserts behavior on argument validation, mocking `AnsibleModule` so no real system calls happen.
3. **Ignore files**: explain `tests/sanity/ignore-<version>.txt`, when adding an ignore is legitimate versus when it's hiding a real bug, and how to keep the ignore list from growing unbounded.
4. **Matrix**: recommend which ansible-core / Python versions to test against based on the collection's stated support, and lay out a CI matrix.
5. **CI wiring**: produce a CI job (GitHub Actions or GitLab CI) that runs `ansible-test sanity` and `ansible-test units` in containers, failing the build on any failure.
6. **Local parity**: give the exact commands a developer runs locally so CI never surprises them.

Fill in:
- Collection namespace.name and layout: [DESCRIBE]
- Modules/plugins to cover: [LIST]
- ansible-core versions to support: [e.g. 2.16, 2.17]
- CI system: [GitHub Actions / GitLab CI / other]

Output format: the `tests/` directory layout, a sample unit test, the sanity invocation, a CI workflow file, and a short policy on when adding a sanity ignore is acceptable.

Do not weaken tests to make CI green. If a sanity check fails, prefer fixing the code over adding an ignore; call out any ignore you propose and why it's safe.