Add screeps transport

[PimentelM]

Make it possible to integrate an agent running inside the game screeps with the bt-studio/server

We should be able to make either the server connect to screeps and poll data from there or come up with a way where screeps itself will talk with the server.

Should be abstracted as a transport.

Thorough research should be conducted to understand the better way of designing that

[PimentelM]

Implementation Notes

Key constraint: Screeps has no outbound networking. Communication via memory segments (100 KB string slots). External tools poll/write via Screeps REST API.

Architecture (fundamentally different from TCP/WS — server polls agent):

[Screeps game] --(writes segment)--> [Screeps API] <--(HTTP polls)-- [Studio Server]
[Screeps game] --(reads segment)---> [Screeps API] <--(HTTP writes)- [Studio Server]

Transport interface: core/src/studio/transport.ts:5-12 — open(), close(), send(), onMessage().

Two-part implementation needed:

1. Agent-side (ScreepsSegmentTransport): send() writes JSON to RawMemory.segments[N]. onMessage() reads from RawMemory.segments[M] each game tick. Zero-dependency (runs in Screeps VM).
2. Server-side (polling bridge): HTTP-polls Screeps API, produces Connection<> objects for MessageRouter/CommandBroker (studio-server/src/index.ts:210-227).

Needs: envelope/sequence-number scheme for dedup, multi-message buffering (100 KB limit), stale data detection.

Open questions:

• Private server vs official? Auth differs.
• Poll interval? Screeps ticks ~3-5s on official.
• Segment IDs configurable per-agent or convention?
• 100 KB enough for tree serialization + tick batches? Compression needed?
• New package (studio-transport-screeps) or in studio-server?
• Agent-side code separate export (runs in Screeps VM, not Node)?

[PimentelM]

Complexity: 7/9
Scope: 2/3 | Uncertainty: 3/3 | Dependencies: 2/3
Screeps runs in a sandboxed JS environment (no raw sockets/WS client), so the transport can't follow the existing TransportInterface pattern (open/send/onMessage over TCP/WS). Requires researching Screeps' IPC options (Memory segments, RawMemory.interShardMemory, external HTTP via screeps-api/screeps-multimeter, or private server mods) to find a viable data channel. The transport interface itself is clean and small (~6 methods), and adding a new transport is scoped (new class + factory), but the core uncertainty around Screeps' constrained runtime and which polling/push strategy actually works makes this high-uncertainty. External dep on Screeps API/ecosystem adds moderate dependency risk.