short-form bypass, dedup HMAC compare

Self-review of feccd09 surfaced two real defects that would have
shipped silently, plus several engineering loose ends. All addressed
in one pass.

# Bugs

## LINE: HMAC verified the wrong bytes

The handler took `axum::extract::Json<Value>` and then re-serialized
via `serde_json::to_vec(&body.0)` to hand to the HMAC verifier.  Once
a body has been parsed into `serde_json::Value` it has lost the
information needed to round-trip back to the original bytes — at
least key order (`Value::Object` is alphabetised) and whitespace.
LINE's HMAC covers the wire bytes, so the round-tripped bytes would
never match the digest the platform sent and **every legitimate
webhook would have returned 401**.

Fix: pull the body in as `axum::body::Bytes`, verify HMAC against
those raw bytes, then `serde_json::from_slice` the JSON
post-verification — the same pattern Messenger / Teams / Viber were
already using in this PR. Added two regression tests:
`test_verify_line_signature_round_trip` and
`test_line_signature_breaks_when_body_round_tripped_through_value`
which constructs `{"b":1, "a":2}`, HMACs it, then proves the
round-tripped form `{"a":2,"b":1}` fails to verify.

## SSRF guard bypassed by IPv6-mapped/NAT64 addresses, `[::]`,
trailing-dot FQDN

A probe over a wider corpus showed:

  * `http://[::]/` → Ok (should reject — `host_str()` returns the
    bracketed `"[::]"` which `IpAddr::from_str` refuses, so the
    private-IP branch never ran).
  * `http://[::ffff:127.0.0.1]/` → Ok (IPv4-mapped IPv6 — packets go
    to `127.0.0.1` on the wire; we never extracted the embedded v4).
  * `http://[64:ff9b::7f00:1]/` → Ok (RFC 6052 NAT64 well-known
    prefix — same problem).
  * `http://localhost./` → Ok (trailing-dot FQDN; the comparison
    against `"localhost"` failed because of the `.`).

(The IPv4 short-form bypasses I worried about in review —
`http://127.1/`, `http://2130706433/`, `http://0177.0.0.1/`,
`http://0x7f.0.0.1/` — turned out *not* to be bypasses: WHATWG URL
parser inside `url::Url::host()` already normalises them to
`Ipv4(127.0.0.1)`. Test cases added to lock that property in.)

Fix: rewrote `validate_url_for_fetch` to branch on
`url::Url::host()` (the `Host<&str>` enum), not `host_str()`. New
helper `ipv6_embedded_ipv4` extracts the embedded IPv4 from
`::ffff:x.x.x.x` and `64:ff9b::x.x.x.x`. Domain branch strips
trailing dots before comparison. Also tightened the IPv4 table:
explicit /24 for `192.0.0.0/24` (was `/16` which over-rejected
`192.0.1.x`), CGN `100.64.0.0/10`, multicast `224/4`, reserved
`240/4`. New test cases cover all of the above.

# Engineering

* **Constant-time compare deduplicated.** Messenger, LINE, Teams,
  Viber each had their own hand-rolled `for ... |= a ^ b` loop. All
  four now call `crate::http_client::ct_eq`, which is backed by the
  `subtle` crate (already a workspace dep). Hand-rolled CT compares
  risk being lowered to early-exit `memcmp` by future compiler
  rounds; `subtle::ConstantTimeEq` is the audited reference.

* **"No secret configured" warning moved to construction.** The
  fall-through warn fired on every webhook request, flooding logs
  whenever an operator left the env var unset. Now logged exactly
  once when the adapter is built. Per-request path stays silent.

* **Teams base64 key cached.** `verify_teams_signature` was
  decoding the configured token from base64 on every request. Now
  decoded once in `TeamsAdapter::new`; misconfigured non-base64
  input collapses to `security_token_key: None` (verification
  disabled, warning logged once) so the hot path stays branch-light.

* **Status codes unified.** Across all five channels:
  - missing/malformed input header → `400 Bad Request`
  - present but rejected (sig mismatch, stale, replay) → `401 Unauthorized`

  Previously they were a mix of 400 / 401 / 403. Operators now get
  a uniform signal in their access logs.

* **`sha1` pinned to 0.10.** Workspace `Cargo.toml` had `sha1 = "0.11"`
  which moved to digest 0.11; `hmac = "0.12"` is on digest 0.10 and
  the two are incompatible — `Hmac::<Sha1>::new_from_slice` won't
  compile. The PR's previous in-progress edit had this right but it
  got reverted somehow. Pinned with a comment explaining the
  pairing.

The previous follow-up commit added new env vars (`app_secret_env` for
Messenger, `security_token_env` for Teams) and changed inbound HTTP
contracts (LINE/Viber/DingTalk are now hard 400/401 instead of silent
bypass). None of that was reflected in user-facing docs, so an
operator reading `configuration/channels/page.mdx` would not know to
set the new env vars and would fall through to the "skip verification
with a warning" backwards-compat path.

Updates:

- New top-of-page **Webhook security** section explaining the uniform
  status-code contract (400 for missing/malformed headers, 401 for
  bad signatures), the constant-time wire-byte HMAC, and the SSRF
  guard on outbound `callback_url`.
- `[channels.teams]` — add `security_token_env` field row with a
  warning that production should always set it.
- `[channels.messenger]` — add `app_secret_env` field row with the
  same warning.
- `[channels.line]` — note that `channel_secret_env` is now strictly
  required (was silently bypassed when the header was absent).
- `[channels.viber]` — note that `auth_token_env` is also the HMAC
  key for inbound verification.
- `[channels.dingtalk]` — webhook mode now rejects missing/non-numeric
  `timestamp` headers with a hard 400.
- `[channels.webhook]` — explicitly document that `callback_url` is
  SSRF-guarded and which ranges are refused.

…dates

The previous docs commit only updated the channels sub-page. The
top-level configuration/page.mdx (independent full reference) and
configuration/security/page.mdx (env var index) duplicate the same
material and were still out of sync.

- configuration/page.mdx: same Teams/Messenger/LINE/Viber/DingTalk/
  Webhook updates as the channels sub-page (new env var fields,
  mandatory-signature notes, callback_url SSRF wording).
- configuration/security/page.mdx: add TEAMS_SECURITY_TOKEN and
  MESSENGER_APP_SECRET to the env-var inventory.