chore: remove stale FIXME on snapshot URL defaults

[kutluhaneth46]

Summary

Remove two stale FIXME: Update this to the actual snapshot URL comments on https://snapshots.arc.network/5042002 — already the production testnet snapshot URL documented in docs/running-an-arc-node.md and used by crates/snapshots.

Fixes #275.

Test plan

• Comments-only change; no behavior change

[osr21]

Verified — this is exactly the two-line removal discussed on #275, and re-checking today confirms it still holds:

• https://snapshots.arc.network/5042002/latest.txt → 200, now pointing at snapshot-arc-testnet-pruned-execution-20260901T2005Z-59988657.tar.lz4 (a newer pointer than when I checked on chore: stale FIXME comments on snapshot URL in execution-config defaults (already the real URL) #275, confirming this is a live, rolling production feed, not a stale placeholder).
• Both DEFAULT_DOWNLOAD_URL and the available_snapshots entry it removes the FIXME from are self-contained to this file — no other crate consumes them, and crates/snapshots/src/download.rs + docs/running-an-arc-node.md independently reference the same host without any "provisional" caveat. Comments-only, no behavior change, matches the test plan.

Two non-blocking items from the #275 discussion that this PR doesn't touch — flagging in case they're wanted here or in a follow-up, not asking for a respin of this diff:

1. Base-URL 404 trap: https://snapshots.arc.network/5042002 (bare) still 404s today — it's a prefix, not a fetchable object; only <base>/latest.txt resolves. Removing the FIXME without a word on that is the one way this exact confusion reappears (a future contributor curls the bare URL, gets a 404, adds a new FIXME). A one-line comment on DEFAULT_DOWNLOAD_URL noting the pointer path would close that loop for good.
2. L40 label-in-URL: Cow::Borrowed("https://snapshots.arc.network/5042002 (testnet)") embeds a " (testnet)" suffix inside the string. Harmless while available_snapshots is display-only, but it stops being a valid URL the moment anything treats that vec as fetchable — worth splitting the label from the URL if this file gets touched again.

Also for completeness: I checked the devnet URL (5042001) independently this time — latest.txt still 404s ("No snapshot available"), same as when the issue was filed. That's ops/data state, not a wrong URL, and doesn't affect this PR's correctness either way.

No conflicts with other open PRs — nothing else in the tree currently touches crates/execution-config/src/defaults.rs.