BOLT-1322 [7/7] api: integration / e2e test for sendCommand(vehicle:check-pairing-status)

Add an integration test (probably under domains/device/src/subgraph/schema/__tests__/ or wherever the existing sendCommand mutation tests live — see domains/device/src/subgraph/schema/__tests__/sendCommand.test.ts if it exists, otherwise model on existing command mutation tests). Cases: 1. POST sendCommand mutation with slug='vehicle:check-pairing-status', deviceOnWorkspaceId pointing to a Tesla vehicle → response includes a Command row with status='pending' (or 'delivered'), output null at first; mock the command.executed handler being invoked and assert output gets populated. (May simplify to just asserting CommandIssuedEvent was emitted.) 2. POST sendCommand mutation with same slug pointing to a non-Tesla vehicle (or non-vehicle if API allows) → response includes Command with status='completed' and output={ keyPaired: null, applicable: false } SYNCHRONOUSLY, no CommandIssuedEvent emitted. 3. Verify the existing 'getAvailableCommands' API returns vehicle:check-pairing-status as an option for vehicle devices regardless of manufacturer (since the API doesn't 400 for non-Tesla — it just answers N/A). 4. Smoke test: malformed payload → standard zod validation error path. Branch: havoc/bolt-1322-integration-tests Worktree: ../mono-bolt-1322-integration-tests Depends on: [1/7] [2/7] [3/7] [4/7] [5/7] [6/7] Done when: integration tests green, can demonstrate sub-second non-Tesla short-circuit and Tesla async-via-Kafka delivery.