A --filter copied from the report's own output silently matches nothing #1237

Problem

The report prints a humanized title. --filter matches the function name, case-sensitively. So the most natural thing a user can do — copy the name they just read — selects nothing and the run ends on a bare No tests found with nowhere to go:

$ bashunit t_test.sh
✓ Passed: Beta case

$ bashunit --filter "Beta case" t_test.sh
 No tests found

It is sharper than it looks: the space is not required. test_alpha prints as Alpha, and --filter Alpha also finds nothing, because the match is case-sensitive. A single word copied verbatim from the output fails.

The project's own agent rules already warn about this ("it matches the function name … so a filter with spaces silently matches nothing"), which is evidence it bites people rather than a hypothetical.

Proposal

The run knows the filter and knows every function it sourced, so an empty selection can explain itself and name the test it most likely meant:

 No tests found
No test matches 'Beta case'. Filters match the function name, not the title: did you mean 'test_beta_case'?

Resolving both differences is what makes it land: lowercase the filter, and put underscores back where the humanized title shows spaces. With no plausible candidate it states the rule instead of guessing.

Constraints

• Only prints when a filter was given, so an empty run for any other reason reads exactly as before — that is what keeps bashunit_path_test_sh.test_bashunit_argument_overloads_default_path.snapshot valid
• Only the filter is lowercased, never the candidate list: no fork per function on a path that has already decided to run nothing
• Must hold in --parallel as well, since the summary renders in the parent but this project has shipped silent mode divergences before (A @data_provider that yields no data makes the test vanish #1145, Duplicate test functions go undetected under --parallel #1147)