Architecture docs still describe retries as idempotent-only, max 3 (predates configurable retry_policy)

[shaneutt]

The architecture docs and review criteria still describe retry behavior as it
was before the configurable retry_policy landed. They present retries as
idempotent-only and capped at 3, which is now only the legacy default (used when
a cluster has no retry_policy), not what a configured policy does.

A configured RetryPolicy supports (and the reference docs already cover this,
e.g. the allow_non_idempotent
row):

• allow_non_idempotent: true to retry POST/PATCH
• a configurable max_retries (default 3, capped at 15 by ServerConf)
• retriable_status_codes / retriable_conditions, so retries can fire on 5xx
  or a reset, not only connect failures

Stale spots:

• pingora-handler-lifecycle.md:272
  ("Only retries idempotent requests (GET, HEAD, OPTIONS)") and
  :278
  ("Allows up to 3 retries")
• pingora-handler-lifecycle.md:449-451
  ("only GET, HEAD, OPTIONS retry" / "maximum 3 retries")
• http-correctness.md:70
  ("retries must only apply to idempotent requests")
• review-criteria.md:35
  ("only for idempotent methods")

The invariant that is still absolute and worth keeping is "never replay after
bytes were written upstream." The idempotency and attempt-count wording should be
updated to describe the configurable policy (with the legacy default called out
as the default), matching the reference docs.

Praxis version: main (v0.5.3 line)