sandbox/docs: mention translations in the unified view; drop architecture.html

Translation forwarding (live pull-RPC + catalog provider) now puts the
sandboxed integration's translations on main alongside its entities,
services, and events — note it in the OVERVIEW + ARCHITECTURE goals.
Remove the generated architecture.html; the architecture is published to
a gist instead of carrying a rendered artifact in the tree.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

sandbox/ARCHITECTURE.md

@@ -19,8 +19,8 @@ running everything locally.
 A user who adds a light integration through the frontend ends up with a device
 plus entities in main's registries, working area targeting (`light.turn_on`
 against an area resolves the sandboxed lights like any other light), and the
-integration's services and events available on main — with the integration code
-only ever executing inside the sandbox.
+integration's services, events, and translations available on main — with the
+integration code only ever executing inside the sandbox.
 
 The sandbox is **stateless**: it holds no persistent state of its own. Its
 storage and restore-state route to main (§9), and even the integration's *code*

sandbox/OVERVIEW.md

@@ -27,8 +27,8 @@
 Run a Home Assistant integration's setup, config flow, entities,
 services, and events fully inside an **isolated subprocess** ("sandbox"),
 while the main HA instance keeps a **single, unified view** of devices,
-entities, services, and events that looks identical to running
-everything locally.
+entities, services, events, and translations that looks identical to
+running everything locally.
 
 A user adding a light integration through the frontend should end up
 with a device + entities in the main instance's registries, area