docs(exn): define payload routing architecture

[Inczert]

Summary

Define the EXN system architecture around logical endpoint responsibilities rather than fixed physical-node routing.

Changes

• add docs/architecture.md as the high-level system architecture authority;
• model Raspberry Pi 5 as an Embedded Linux Payload Platform hosting independent Camera and Antenna/Communications services;
• reserve PI-COMMS as APID 0x103 / Source ID 0x04 and document flight-like GS -> communications -> OBC ingress;
• keep the STM32 OBC as command/control authority while allowing bulk payload data to bypass it;
• define FPGA as an image/AI processing endpoint only;
• make FPGA processing-result routing configurable via result.route_mask, allowing requester, OBC, Camera, Communications, or multicast delivery;
• allow direct Camera -> Communications and FPGA -> Communications data paths;
• document Linux supervision/watchdog/service boundaries;
• document SpWKit as an optional logical-link/simulation layer capable of carrying multiple EXN logical links over shared Ethernet;
• explicitly keep private/commercial FPGA SpaceWire implementations outside EXN scope;
• update sequence diagrams and endpoint ICDs to match the new model.

Routing rule

Processing output is not tied to one fixed FPGA -> Camera or FPGA -> OBC path. Destination is selected by processing/mission policy. Classification results may feed OBC autonomy, processed products may return to Camera, and results may go directly to the Communications service for downlink when a ground link is available.

Compatibility

The existing TC 210/1 layout is retained. Current configurable routing is expressed through Service 210 settings; a future compatible interface revision may add a per-execution route override.

No spwkit-fpga dependency or EXN architecture role is introduced.