fix(dispatch): report a taken app id instead of a 500

[samijaber]

What happened

Creating a workspace app whose id is already taken returned {"error":"Internal server error"} in the create-app popover, with no indication of the real cause.

startWorkspaceAppCreation checks for an id collision in two places, and neither call was inside a try:

• assertPendingWorkspaceAppCreationAvailable — a pending creation owned by another member
• reservePendingWorkspaceApp — a registered app, or a pending creation owned by anyone, including the caller

Each builds a message that names the conflict and, for an in-flight creation, who holds it. Both threw, so the action route flattened them to a generic 500 and that message never reached the UI or chat.

The second gate is what users actually hit: start an app, have it stall in pending, retry the same prompt, get "Internal server error" with nothing to act on.

Changes

• WorkspaceAppIdTakenError carries appId, conflict ("registered" | "pending") and owner. Both collision paths throw it.
• startWorkspaceAppCreation converts only that error into a new app-id-taken result mode. Registry and storage failures from the same helpers keep propagating — an unreadable app registry stays a fault, rather than being reported as a name the caller can simply change.
• workspace-template-card fell through to toast.success(labels.remixSuccess) for any mode it did not recognize, so this result would have rendered a green "remixed" toast on a failure. It now reports it as an error.
• simple-agents-panel's result union and the start-workspace-app-creation agent instructions in integrations.ts both learn the new mode.

The create-app popover and NewWorkspaceAppFlow needed no change: their fallback branch already renders result.message, which is exactly what was being thrown away.

This follows the repo's own rule that a failure coerced into a value callers cannot distinguish from success is a bug — the template card's silent-success default was that shape.

Testing

• app-creation-store.spec.ts: 63 passed. The two cross-member collision tests now assert the typed result instead of a throw, plus a new test covering the same-owner in-flight case that produced the original 500.
• Full packages/dispatch suite: 737 passed, 0 failed.
• oxfmt run on all modified files; changeset added.

Four spec files in the full run fail to load with Failed to resolve import "qrcode.react", and 13 tsc errors remain — all from stale dependencies in my local checkout (@agent-native/core will not build: missing @better-auth/scim). None are in the files this PR touches, and none are test failures.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Code Review Summary

PR #5629 changes workspace app creation so registered and pending app-ID collisions become a typed app-id-taken result instead of an unhandled exception that is flattened to a generic 500. The implementation introduces WorkspaceAppIdTakenError, converts only that error at both collision gates, preserves registry/storage failures as real faults, extends the result union and agent instructions, and makes the template-card path show an error toast rather than falling through to success. The approach is sound and keeps the collision-specific recovery information (appId, conflict type, and pending owner) available to callers. Tests cover cross-member and same-owner pending collisions, and both independent code-review passes found no actionable issues. Risk assessment: Standard, because this changes shared dispatch business logic and several UI result consumers, but does not alter authentication, payments, schema, or destructive mutation behavior.

Findings

No confirmed actionable findings.

✅ Good coverage of the two previously unhandled collision paths.
✅ Catch blocks are deliberately narrow, so unreadable registry/storage state is not misreported as a user-fixable name conflict.
✅ The template-card unknown-result success fallthrough is corrected for the new mode.

🧪 Browser testing: Attempted after review; 0/11 cases could be verified because browser executor sessions did not expose Chrome navigation/snapshot/click/screenshot tools. The dev server was healthy, and this is an infrastructure limitation rather than an application failure.