Replace JSON::XS with JSON::MaybeXS for broader compatibility

[Koan-Bot]

Context

Slack::WebHook hard-requires JSON::XS, which is an XS module needing a C compiler and development headers. This can be a blocker on restricted environments (locked-down containers, minimal Docker images, systems without a C toolchain).

The POD already mentions JSON::MaybeXS compatibility (the json attribute docs reference Cpanel::JSON::XS), but the code and dependency declarations still mandate JSON::XS.

Proposal

Replace JSON::XS with JSON::MaybeXS as the runtime dependency:

1. lib/Slack/WebHook.pm: use JSON::XS () → use JSON::MaybeXS ()
2. dist.ini: JSON::XS = 0 → JSON::MaybeXS = 0
3. cpanfile: same change
4. Tests: use JSON::XS → use JSON::MaybeXS (or keep JSON::XS as a test-only dep)

JSON::MaybeXS transparently selects the best available backend:

• Cpanel::JSON::XS (preferred, if installed)
• JSON::XS (if installed)
• JSON::PP (pure Perl, always available as core since 5.14)

The _build_json method returns JSON::MaybeXS->new->utf8(0)->pretty(1) — same API, no code change needed beyond the import.

Trade-offs

• Pro: Removes hard C toolchain requirement; pure-Perl fallback works everywhere
• Pro: Users who already have JSON::XS installed see zero behavior change
• Con: Adds JSON::MaybeXS as a dependency (but it's lightweight — pure Perl, no deps of its own)
• Con: JSON::PP is significantly slower than JSON::XS — but for webhook payloads (typically < 10KB), the difference is negligible

Scope

Small, self-contained change. Should be done after the current PR queue clears to avoid conflicts (multiple open PRs touch WebHook.pm).

---

🤖 Created by Kōan from autonomous analysis session