[ProgenyAlpha]

Summary

Adds an opt-in sync type fleets that sends fleet records: what each of your fleets is doing (state, cargo, mining node and timer, repair and travel timers, hull and shield). Off by default; only sent to targets that enable it.

Why: the existing sync types cover what you own, not what your fleets are doing, so a receiver can't show "mining, full in 40 min" or "warping, arriving 2:10" without screenshots.

What changes

• fleets under [sync] and per target (one SyncOptions row, config.cc untouched). English example only.
• Client records (src: client), from the existing fleet_watch observer: one per state change, plus a snapshot of all slots at login.

  {"type":"fleet","src":"client","fid":2810669496199887731,"slot":1,"hull_id":1029262994,"level":33,
   "state_name":"Mining","prev_state_name":"Impulsing","is_mining":true,"cargo":382,"cargo_max":7623,
   "node_resource":1779416627,"node_amount":18000,"occupied_since":1792725830,"mining_due":1792729728,"t":1792725834}

  Depending on what the ship is doing they also carry repair_due, travel_due (warp/impulse arrival) and hull_damage (docked only).
• Server records (src: server): the MyDeployedFleets entity group already reaches HandleEntityGroup. With fleets on it's parsed into system, hull and shield, cargo cap, warp range, strength and pursued_by (a count). Only fleets whose record changed are sent; no ids of other players.
• Repair jobs include the fleet id when fleets is on.
• MyDeployedFleetsResponse is in its own stfc.sync.proto because the game doesn't declare it and regenerating the Digit protos would drop it.
• No new hook, no new server call.

Notes

• The client fills in some values (mining and travel timers, damage) from server data that arrives after the state change. When the server sends new data for a fleet, it's re-read a second later and resent if those values changed. Nothing polls (see Protect sync consumers from repeated failed uploads and uncontrolled outage traffic #275, Investigate shared runtime work across features: frame hooks, scans, timers, and polling #286).
• hull_damage is only sent while docked: the client doesn't keep it current in space, where the server's hull points are the live value.
• mining_rate is the game's mining multiplier, not resources per hour. The real rate is node_amount or the free cargo, whichever runs out first, over mining_due - occupied_since.
• Added prev_state_name as requested.

Verified

Windows, mod built from dev + this change, against a local sync target: warp and impulse with arrival times, mining through to full hold and empty node, fights, a destroyed ship, repair with the job's fleet id, and login snapshots. macOS not tested.

Checks

Local MSVC release build clean; macOS not built locally. No CHANGELOG or version changes.

[ProgenyAlpha]

Tested in-game on Windows (build from this branch, fleets = true under [sync]): after login the receiver got a 3-fleet first-sync snapshot within ~15 s, then single fleet records on each transition (WarpCharging → Warping → Docked observed), with state_name, hull_id and slot as described. No fast polling, no visible impact on the game.

[ProgenyAlpha]

Rebased onto dev (the PR target per AGENTS.md) and dropped the non-English example-config edits per the current guideline. Second commit fixes a real bug found in play: HullSpec::Id is read as a 32-bit long, so hull ids past 2^31 (Kumari, Jellyfish) came out negative in the records; the value is now widened as unsigned. Release build on dev: build ok, git diff --check clean.

[netniV]

To be consistent, shouldn't we include prev_state_name too?

[netniV]

@ProgenyAlpha -- Please see my previous comments and you also need to rebase now as there are conflicts.

[ProgenyAlpha]

I've been working on this significantly since original PR. Will update once I have it dialed in.