fix(platform): accept sandbox controllers without echoed binding props (#349)

Fixes #344

## Problem

Every managed Sandbox deploy failed at `worker_upload` with:

```
Sandbox controller authority binding differs from this deployment.
```

`provisionSandboxController` uploads the `void-sb-*` controller with a
`service` binding that carries `props`, then reads `/settings` back and
required the same `props`. Cloudflare applies `props` at runtime but
never returns them:

```
PUT  script, service binding + props  → 200, target entrypoint sees ctx.props ✓
GET  /settings                         → { entrypoint, environment, name, service, type }  (no props)
GET  /bindings, /versions/{id}         → same, no props
```

(Checked against the live Cloudflare API with throwaway scripts.) So the
check rejected even a freshly created controller. The integration mock
echoed uploaded bindings verbatim, which hid this.

## Fix

- Drop the `props` comparison in `assertConfiguration`. Keep the
`service` and `entrypoint` checks. The plain-text identity bindings
(`__VOID_SANDBOX_OWNER`, `__VOID_USER_ID`, `__PROJECT_ID`,
`__VOID_PROJECT_SLUG`, `__VOID_DEPLOYMENT_ID`) come from the same upload
and are still checked; `SandboxControl` still verifies each admission
against the database.
- The Cloudflare mock now returns the real `/settings` shape (no
`props`, adds `environment`). With the old assertion, the sandbox
integration suite fails with the production error.

Also confirmed live: `/settings` returns `namespace_id` for the
controller's Durable Object binding, including with `containers`, so the
next check in this path holds.

## Verification

- `vp test run --project platform-api-integration
platform/packages/api/test/integration/api-sandbox.test.ts`: 15/15
- `vp test run --project "platform-*"`: all pass
- `@voidcloud/api` typecheck: pass

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Author: Brooooooklyn

platform/packages/api/src/provisioning/sandbox-controller.ts

@@ -33,7 +33,6 @@ type WorkerSettings = {
     namespace_id?: string;
     service?: string;
     entrypoint?: string;
-    props?: Record<string, unknown>;
   }>;
 };
 
@@ -134,18 +133,12 @@ function assertConfiguration(
       throw new Error(`Sandbox controller binding ${name} differs from this deployment.`);
     }
   }
+  // Cloudflare does not return service binding `props` from `/settings`. The
+  // plain-text bindings checked above come from the same upload as the props.
   const control = settings.bindings.find(
     (binding) => binding.type === 'service' && binding.name === '__VOID_SANDBOX_CONTROL',
   );
-  if (
-    control?.service !== apiService ||
-    control.entrypoint !== 'SandboxControl' ||
-    !control.props ||
-    control.props.projectId !== identity.projectId ||
-    control.props.deploymentId !== identity.deploymentId ||
-    control.props.userId !== identity.userId ||
-    control.props.slug !== identity.slug
-  ) {
+  if (control?.service !== apiService || control.entrypoint !== 'SandboxControl') {
     throw new Error('Sandbox controller authority binding differs from this deployment.');
   }
   namespaceId(settings);

platform/packages/api/test/integration/helpers.ts

@@ -1620,8 +1620,18 @@ export function mockCfApi(overrides: Partial<CfApiMocks> = {}): MockCfApiHandle
       if (method === 'GET' && url.endsWith('/settings')) {
         const name = parseScriptNameFromUrl(url);
         const script = name ? state.hostScripts.get(name) : undefined;
+        // Cloudflare accepts `props` on a service binding upload and applies
+        // them at runtime, but never echoes them from `/settings`.
         return script
-          ? cfSuccess({ bindings: script.bindings })
+          ? cfSuccess({
+              bindings: script.bindings.map((binding) => {
+                if (binding.type !== 'service') {
+                  return binding;
+                }
+                const { props: _props, ...rest } = binding;
+                return { ...rest, environment: 'production' };
+              }),
+            })
           : Response.json(
               { success: false, errors: [{ code: 10007, message: 'script not found' }] },
               { status: 404 },