fix(busbar-150): mount at the DEFAULT paths and pre-supply the signing key - it boots

Root cause of three failed boots: launch.env's '-e' args did not reach the
container. busbar was reading the IMAGE'S BUILT-IN /etc/busbar/config.yaml the
whole time, which is why it complained about a provider named 'anthropic' and an
ANTHROPIC_KEY that appear nowhere in this manifest. BUSBAR_CONFIG never took
effect, so pointing the mounts at /work pointed them at nothing busbar read.

Verified locally against the real image, with the exact mount layout the box
uses:

  * config and providers mount at /etc/busbar/{config,providers}.yaml, the
    defaults, which provably work
  * auth.signing_key is a documented secret reference to a mounted file, so
    1.5.0 never needs to write to read-only /etc/busbar. The key was generated
    by this very image; with chain: [] it signs nothing the benchmark uses, so
    it is a throwaway dev artefact rather than a credential
  * BUSBAR_ADMIN_TOKEN and BUSBAR_STATE_FILE go in the env FILE, the path that
    demonstrably reaches the container (it is how BENCH_MOCK_KEY resolves).
    Empty BUSBAR_STATE_FILE stops a per-tick state-snapshot retry against a
    read-only path - noise inside a measurement window

Local result: boots, listens on 8000 and 8081, zero state-snapshot failures.

Also read the docs properly this time - /docs/migration-1-5/ and
/docs/deploy/docker/ exist and I had been reverse-engineering from boot errors
instead of reading them.

Author: MattJackson

gateways/busbar-150/busbar-signing.key

@@ -0,0 +1 @@
+958e2e82eff7734785a51d4c8f9244806b22a2338639291241670d12323393f9

gateways/busbar-150/config.gen.yaml.tmpl

@@ -67,3 +67,11 @@ models:
 # the board's rule is the bare minimum required to run.
 auth:
   chain: []
+  # A PRE-SUPPLIED KEY, because /etc/busbar is read-only in the image. 1.5.0 generates and persists an
+  # ed25519 signing key on first boot when this is omitted, and cannot: 'cannot install signing key
+  # /etc/busbar/busbar-signing.key: Permission denied'. Declaring the documented secret reference to a
+  # mounted file removes the need to write at all. With chain: [] this key signs nothing the benchmark
+  # uses - the data plane is unauthenticated, matching what 1.4.1 ran - so it is a throwaway dev key
+  # generated by this very image, not a credential.
+  signing_key:
+    file: /etc/busbar/busbar-signing.key

gateways/busbar-150/definition.json

@@ -32,30 +32,20 @@
   "lang": "Rust",
   "launch": {
     "args": [],
-    "env": [
-      [
-        "BUSBAR_CONFIG",
-        "/work/config.yaml"
-      ],
-      [
-        "BUSBAR_PROVIDERS",
-        "/work/providers.yaml"
-      ],
-      [
-        "BUSBAR_ADMIN_TOKEN",
-        "bench-admin-token"
-      ]
-    ],
     "image": "getbusbar/busbar:1.5.0",
     "kind": "docker",
     "mounts": [
       {
-        "container_path": "/work/config.yaml",
+        "container_path": "/etc/busbar/config.yaml",
         "host_path": "config.gen.yaml"
       },
       {
-        "container_path": "/work/providers.yaml",
+        "container_path": "/etc/busbar/providers.yaml",
         "host_path": "providers.gen.yaml"
+      },
+      {
+        "container_path": "/etc/busbar/busbar-signing.key",
+        "host_path": "busbar-signing.key"
       }
     ]
   },

gateways/busbar-150/env

@@ -1,3 +1,4 @@
 BENCH_MOCK_KEY=dummy
 BENCH_BEDROCK_KEY=AKIAMOCKACCESSKEY:mock-secret-access-key
 BUSBAR_ADMIN_TOKEN=bench-admin-token
+BUSBAR_STATE_FILE=