feat(cli): --exclude-filter to skip tests by name

[Chemaclass]

Problem

Selection by name is one-directional. --filter <name> includes; there is no way to exclude by name. Tags have both (--tag / --exclude-tag), names do not.

The common case is "run everything except the handful of tests matching slow_network" without going back and tagging them first. bats-core ships --negative-filter <regex> for exactly this.

Proposal

--exclude-filter <name>   Skip tests whose name matches (repeatable)

• Matching semantics identical to --filter, so the two are symmetric and predictable.
• Repeatable; a test is skipped if it matches any --exclude-filter.
• Exclusion wins over inclusion, mirroring how --exclude-tag beats --tag.
• Works together with --tag, --shard, --rerun-failed.

Where to change

• src/helper/discovery.sh:62 get_functions_to_run — the include decision is made here.
• src/main/test.sh flag parsing, src/config/env.sh for BASHUNIT_EXCLUDE_FILTER.

Acceptance criteria

• --exclude-filter foo runs every test except those matching foo
• --filter user --exclude-filter admin runs user tests that are not admin tests
• Repeated --exclude-filter flags are OR'd
• Exclusion wins when a name matches both --filter and --exclude-filter
• Excluded tests are not reported as skipped — they are not selected at all (same as --exclude-tag)
• Works with file::fn and file:LINE targeting
• Unit tests in tests/unit/helper/discovery_test.sh plus an acceptance test

Repo checklist (agent)

• TDD: RED → GREEN → REFACTOR. Write the failing test first.
• Bash 3.0+ only: no printf -v, no += append, no declare -A, no [[ ]], no ${var,,}, no &>>, no ${arr[-1]}. Expanding a possibly-empty array under set -u needs ${arr[@]+"${arr[@]}"}.
• A new CLI flag must be wired in all of these or a parity test fails:
  • parse in src/main/test.sh (report-style flags need export -n, see src/main/test.sh:188-196 for why)
  • validate the value in bashunit::main::validate_config_or_exit (src/main/validate.sh:60) — unvalidated input used to run the wrong thing and exit 0 (Unknown options are silently ignored: a typo'd flag runs a different suite and exits 0 #871, --jobs with a non-integer value hangs on Bash 3.x and is silently ignored on Bash 4.3+ #873)
  • default + env var in src/config/env.sh and a documented line in .env.example
  • --help text in the same block it belongs to
  • both completions/bashunit.bash and completions/_bashunit (anti-drift test feat(cli): bash and zsh completion scripts with an anti-drift test #778 fails otherwise)
• Gates: make sa, make lint, ./bashunit tests/, ./bashunit --parallel tests/. Never run shfmt -w.
• Docs: update docs/command-line.md. Editing docs/assertions.md invalidates the bashunit doc acceptance snapshot — regenerate it.
• CHANGELOG.md: add one line under ## Unreleased.
• Fixtures under tests/acceptance/fixtures/ must not end in *test.sh.
• One issue = one PR.

[Chemaclass]

Done in #1036 (merged).

All acceptance criteria met.

Design note. The value is read from BASHUNIT_EXCLUDE_FILTER inside get_functions_to_run rather than threaded through as a new argument. That function is reached from two places — the header count (inside a subshell) and the runner (main shell) — so passing it to only one would print a count the run then contradicts. Excluded tests are therefore never selected, not reported as skipped.

Bash 3.0 lesson. Five unit tests passed on 3.2 and 5.3 and failed on the floor. Cause was in the tests, not the feature: local functions=(...) — declaring and initialising an array in one statement — is unsupported on Bash 3.0 and stores the literal text, so the helper received prefix_beta prefix_gamma). The neighbouring tests in that file already carry a "Bash 3.0 compatible: separate declaration and assignment" comment that I did not follow.

Worth recording for the rest of the queue: I now build the same Bash 3.0 image CI uses (docker build from .github/workflows/tests-bash-3.0.yml) and run against it locally, which turned a red CI round-trip into a one-minute check. My first diagnosis from the CI log alone — a misparsed multi-line case — was wrong; the local 3.0 build disproved it in one run.