refactor(net-scan): drop report_ping_status sugar and restore probe=ping baseline

Three follow-up tweaks against the plan spec after the earlier fix-up
(`fix(net-scan): restore probe=ping default events and enable_failure
semantics`) was reviewed:

1. Drop the `report_ping_status` query parameter. Plan §4 lists it but
   the recommended .NET mapping never uses it — the field translates to
   `report_ping_success && report_ping_failure` at the call site instead.
   It was introduced in this PR and never shipped, so removing it has
   no downstream consumer impact.

2. Restore the pre-PR behavior for `probe=ping`:
   - The COMMON_PORTS fallback now triggers only when the caller sent no
     `probe=` at all. An explicit probe list (even one containing only
     `ping`) is honored verbatim. Discriminator changed from
     `typed_ports.is_empty()` to `val.probes.is_empty()`.
   - `has_ping_probe` no longer auto-enables `report_ping_failure`.
     Pre-PR clients that sent only `probe=ping` received start + success
     events; failure events required `enable_failure=true`. The earlier
     fix-up coupled failure to `has_ping_probe`, which went beyond what
     the baseline did.

3. Expand the doc comment on `enable_failure` to call out that the
   historical "both ping- and TCP-probe-failure at once" semantics is
   split: clients that want the old behavior must send
   `enable_failure=true&report_tcp_failure=true` together.

Tests:
- Rename `..._enables_ping_start_success_and_failure_events` →
  `..._enables_ping_start_and_success_only`, flip the failure assertion.
- Add `query_mapping_probe_ping_alone_does_not_fallback_to_common_ports`.
- Add `query_mapping_no_probe_falls_back_to_common_ports`.
- Add `query_mapping_probe_ping_with_explicit_port_uses_only_that_port`.
- Add `query_mapping_enable_tcp_probes_false_overrides_explicit_ports`.
- Drop the `report_ping_status` dimension from the boolean-toggle
  permutation matrix and simplify the related assertion right-hand sides.

Author: irvingoujAtDevolution