docs(readme): split supported migration paths by v4 source version

[vaishakdinesh]

What changed

cloudflare_ruleset's state-upgrade bug only fires when v4 state contains asset_name (added v4.52.8) or content_converter (added v4.52.9) — fields the v5 source schema doesn't fully support parsing until v5.22.0+ (and even then only asset_name; content_converter remains unhandled through v5.23.0). v4.52.5–v4.52.7 never write either field, so ruleset migrates cleanly from that range on every target version.

Confirmed empirically: live-tested a direct v4.52.5 → v5.19.1 migration of cloudflare_ruleset and cloudflare_api_token against real Cloudflare infrastructure. ruleset applied with zero references to either field in plan/apply/error output. The only failure was the already-documented api_token policies-swap bug, unrelated to v4 source version.

• Split Supported Migration Paths into two source-version bands (v4.52.5–v4.52.7 vs v4.52.8–v4.52.9) with per-version known-issue counts
• Added a dedicated "Migrating from v4.52.5 – v4.52.7 specifically" section with a full resource-by-resource breakdown per target version, and a clear recommendation (target v5.22.0 — only d1_database remains, which tf-migrate already works around)
• Dropped v5.19.0 from both tables (out of practical scope going forward) and renumbered the now-orphaned footnote
• Rewrote footnote 5 to state the mechanism precisely (which fields, which v4/v5 versions) and point to the new section instead of hedging with "likely unaffected"