fix(wazuh_decoder_rule_tool): make generated decoders match real Wazuh

Measured the tool end to end against wazuh-logtest over 26 log formats,
grading each run by whether the *generated* decoder fired rather than
whether any decoder did. Five defects let broken decoders report success:

* OS_Regex \p was modelled as full punctuation, but wazuh-logtest excludes
  `~ @ ^ _ / \` and a backtick. A `~PAYGW~` or `~AUDIT~` header generalized
  to \p verified clean via osregex_matches() and matched nothing in
  production. Restrict the class to what Wazuh implements and keep such
  characters literal when generalizing.

* A `[` at position 0 collapsed the header zone to "", so
  derive_parent_prematch() returned None and the parent shipped with no
  prematch at all — every log opening with a bracket (epoch stamps, apache
  dates) lost one.

* Weekday names stayed literal while months were generalized, pinning a
  decoder to Mondays. Neither the generalizer nor detect_overfit_prematch
  covered them, so it passed logtest against its own sample.

* /api/ai/generate-validated computed needs_custom_decoder and ignored it,
  emitting a redundant decoder for logs Wazuh already decodes (json, sshd,
  fortigate, ...). The built-in wins Phase 2, so the generated decoder never
  fired while validation still reported success. Route those to a rule keyed
  with <decoded_as>, validated by asserting the generated rule id fires —
  the decoder validator cannot check that, since the built-in satisfies it
  regardless of what the rule does.

* parse_logtest_output() searched the whole output for the first `id:`,
  picking up a Phase 2 decoded field instead of the Phase 3 rule. `id` is a
  documented Wazuh static field, so any decoder extracting an event code
  misreported rule_id. Scope the rule lookups to the Phase 3 block.

Also carries the order-name normalization and _affix_match tightening that
were already in the working tree.

Author: Hasitha9796