feat(bridge)!: guild rosters and per-member leaves, on protocol 4

Protocol 2 could say how many members a guild had, not who they were, and there
is no EventSink for leaving a guild — so PROTOCOL_2.md §10.1 deferred the whole
membership half. This closes it.

The sweep now holds each guild's member serial **set** instead of folding it into
the signature as a sum. That buys two things. A set comparison cannot collide,
where a sum could: one member joining and another leaving between two passes
offset each other and the guild looked unchanged. And a set can be *differenced*,
which is what makes a per-member `guild.leave` possible without a core tap —
departures are simply the prior set minus the current one.

A changed set also re-emits `guild.roster`, the full member list. That is what
lets the departure events stay advisory: a consumer building a "so-and-so left"
feed wants them, but a consumer holding a membership table only needs the roster,
so nothing downstream has to replay deltas to stay correct. On a guild's first
sweep there is no prior set, so nothing is reported as leaving — an unknown
roster becoming known is not 155 people leaving at once.

A roster is the only fat frame this plugin emits — measured at roughly 69 bytes
per member against a real 155-member guild — and the sidecar reads a line with no
length bound. So members per frame are capped (default 500, about 35 KB), and a
guild over the cap is split into frames carrying `seq`, `more` and `total`. Every
realistic guild emits exactly one frame with `seq` 0 and `more` false, which is
the same shape as if chunking did not exist. Verified against the real sidecar
with the cap forced down to 50, which produced 50/50/50/5 across four frames.

The reconnect baseline is spread rather than fired in one pass. `OnConnected`
clears the diff caches, so every guild looks changed at once, and building
hundreds of fat frames in a single Core-thread tick is exactly the stall this
bridge exists to avoid. At most GuildRosterGuildsPerTick guilds emit a roster per
sweep; a guild over budget keeps its old member set, so it still reads as changed
next pass. The sweep re-arms itself after 2s while a baseline is draining, so
catch-up takes seconds rather than one full sweep interval per batch.

BridgeJson gained the array writer it never had — there was no way to express a
list of objects at all. Every field helper emits a leading `,"name":`, so Actor
is split into a bare-object writer that both the single and array forms use.

overlay.toml protocol -> 4, in this commit rather than a later one: CI folds it
into the release manifest and the installer refuses to pair an overlay and a
sidecar that disagree, so a bump landing separately from the emitters would
silently fail to compose into a bundle.

Verified on a live ServUO shard against the real Rust sidecar (not a stub): 155
members seeded from real PlayerMobiles, four roster frames reassembled to 153
entries on the board after two members were removed, two guild.leave frames with
the correct serials, and the departed serials absent from the re-emitted roster.

Refs: docs/website/TEAMS.md Part 12 Phase 1

Co-Authored-By: Claude <noreply@anthropic.com>

overlay/Config/Bridge.cfg

@@ -34,6 +34,18 @@ PageSweepSeconds=5
 # interval (emit guild.update / guild.remove). Guild membership moves slowly; 60s is ample.
 GuildSweepSeconds=60
 
+# Members per guild.roster frame (Protocol 4). A roster is the only fat frame the bridge emits
+# (~69 bytes per member) and the sidecar reads a line with no length bound, so this caps it; a
+# guild over the cap is split across continuation frames carrying seq/more. 500 members is ~35 KB,
+# past any realistic guild, so the split path is an edge case rather than the norm.
+GuildRosterMembersPerLine=500
+
+# Guilds that may emit a roster in one sweep. Every guild looks changed right after a sidecar
+# reconnect, and building hundreds of fat frames in a single Core-thread pass is exactly the stall
+# the bridge exists to avoid. The sweep re-arms itself every 2s while a baseline is draining, so
+# lowering this slows the catch-up without making the site wait a full sweep interval per batch.
+GuildRosterGuildsPerTick=25
+
 # Town-governor poll. Each city's Governor / election is diffed on this interval to emit
 # city.update on change. Governors turn over on the order of weeks, so a slow sweep is fine.
 # Idle (emits nothing) unless the City Loyalty system is enabled (CityLoyalty.Enabled).