fix(project-create): preserve ApiError type so 4xx errors are silenced (#775)

## Summary

Fix [CLI-196](https://sentry.sentry.io/issues/7420270756/) where
`project create` failures were being captured as Sentry issues even for
user-permission errors (17 events from 5 users across 5 orgs in 24h).

## Root cause

`createProjectWithErrors` catches `ApiError` from
`createProjectWithDsn`. For unhandled status codes, it was wrapping in a
generic `CliError`:

```ts
throw new CliError(
  `Failed to create project '${name}' in ${orgSlug}.\n\n` +
    `API error (${error.status}): ${error.detail ?? error.message}`
);
```

This **loses the `status` field**. `classifySilenced` in
`error-reporting.ts` only silences `ApiError` with status 401–499, so
403 "Your organization has disabled this feature for members" became a
Sentry issue.

## Fix

Re-throw as `ApiError` preserving `status`/`detail`/`endpoint`.
User-facing output is unchanged (`ApiError` extends `CliError` and
`.format()` renders the wrapped message). The 4xx silencing now applies
— 403s go to the `cli.error.silenced` metric with org/user context, not
to Sentry as noisy issues. 5xx and network errors (status 0) continue to
be captured as legitimate signals.

Test updated to assert the preserved `ApiError` type and `status: 403`.

Author: BYK

src/commands/project/create.ts

@@ -255,9 +255,19 @@ async function createProjectWithErrors(opts: {
         // createProjectWithDsn's return type differs from SentryProject
         return await (handleCreateProject404(opts) as never);
       }
-      throw new CliError(
-        `Failed to create project '${name}' in ${orgSlug}.\n\n` +
-          `API error (${error.status}): ${error.detail ?? error.message}`
+      // Re-throw as ApiError (not CliError) so the 401–499 user-error
+      // silencing in error-reporting.ts applies — e.g. 403 "Your organization
+      // has disabled this feature for members" is a permission issue, not a
+      // CLI bug. 5xx and network errors still get captured.
+      //
+      // The message is kept short — ApiError.format() appends `detail` and
+      // `endpoint` on separate lines, so embedding them in the message would
+      // duplicate the output.
+      throw new ApiError(
+        `Failed to create project '${name}' in ${orgSlug} (HTTP ${error.status}).`,
+        error.status,
+        error.detail,
+        error.endpoint
       );
     }
     throw error;

test/commands/project/create.test.ts

@@ -417,20 +417,28 @@ describe("project create", () => {
     expect(err.message).toContain("Common platforms:");
   });
 
-  test("wraps other API errors with context", async () => {
+  test("wraps other API errors with context, preserving ApiError type", async () => {
     createProjectSpy.mockRejectedValue(
       new ApiError("API request failed: 403 Forbidden", 403, "No permission")
     );
 
     const { context } = createMockContext();
     const func = await createCommand.loader();
 
-    const err = await func
+    const err = (await func
       .call(context, { json: false }, "my-app", "node")
-      .catch((e: Error) => e);
-    expect(err).toBeInstanceOf(CliError);
+      .catch((e: Error) => e)) as ApiError;
+    // Stays ApiError (not a plain CliError wrapper) so the 401–499
+    // user-error silencing in error-reporting.ts still applies.
+    expect(err).toBeInstanceOf(ApiError);
+    expect(err.status).toBe(403);
+    expect(err.detail).toBe("No permission");
     expect(err.message).toContain("Failed to create project");
     expect(err.message).toContain("403");
+    // Detail is NOT duplicated in message — ApiError.format() appends it.
+    expect(err.message).not.toContain("No permission");
+    // But format() surfaces it for the user
+    expect(err.format()).toContain("No permission");
   });
 
   test("outputs JSON when --json flag is set", async () => {