Back conquests/battles with real data + real-time updates

Problem

conquests.stx and battles.stx render entirely from seedConquests — there is no Conquest model/table/endpoint, no 'contest' API, and the 'Live'/'Under Attack' badges are just status==='active' on seed rows. Period filters slice seed timestamps client-side. No websocket/poll.

Acceptance

• Serve real conquest history (from TerritoryHistory or a Conquest endpoint).
• Real 'under attack'/live state (poll or websocket) instead of scripted seed.
• Battles/conquests pages read the API.

Done — all three, including the real-time half I wanted to check before closing this.

• Real conquest history. GET /api/territories/battles → Actions/Territory/TerritoryBattleIndexAction, serving persisted events (conquered, split, contested, defended) rather than seed rows.
• Real live state, by polling. resources/composables/useBattleFeed.ts fetches /api/territories/battles?limit=200 on mount and every 15s after, hydrating the store and clearing its timer on destroy. useWildloopApp turns it on for /battles, /challenges, /conquests, /feed, /territories and /territory, and off everywhere else.
• The pages read the API. battles.stx and conquests.stx both read wl.conquests(), which hydrateConquestsFromApi() fills from that poll. seedConquests no longer exists anywhere in resources/.

The "Live"/"Under Attack" badge is no longer status === 'active' on a seed row either — TerritoryBattleIndexAction works it out from the persisted events, and its own comment states the rule: a contest is live only while the land is still marked contested.

What this issue listed as an alternative, a websocket, was not built. A 15-second poll on six routes is the cheaper answer and it satisfies what was asked for; if the latency ever matters, that is a new issue with a number attached to it rather than an open box here.