feat(error)!: require .withMessage() as terminal builder step (breaking)

[braden-w]

The old createTaggedError API had a design flaw: every call site had to pass message as a string, even though most errors of the same type use the same message pattern. This led to duplicated message strings scattered across the codebase, and nothing stopped you from forgetting message entirely (TypeScript would catch it, but the intent was unclear). Worse, the builder returned factory functions and chain methods on the same object, blurring the line between "still configuring" and "ready to use."

This redesign introduces .withMessage(fn) as a required terminal step on the builder. It's the gate between configuration and usage — you don't get factory functions until you've defined how messages are computed.

createTaggedError('FileError')          ← ErrorBuilder (chain methods only)
  .withContext<{ path: string }>()      ← ErrorBuilder (chain methods only)
  .withCause<DbError | undefined>()    ← ErrorBuilder (chain methods only)
  .withMessage(({ context }) =>         ← FinalFactories (factory fns only)
    \`File op failed: \${context.path}\`)

The builder object has .withContext(), .withCause(), and .withMessage() — no factories. The object returned by .withMessage() has FileError() and FileErr() — no chain methods. You can't accidentally destructure factories from a half-configured builder.

Before / After

Before — message was a required field at every call site:

const { ApiError, ApiErr } = createTaggedError('ApiError')
  .withContext<{ endpoint: string }>();

ApiErr({
  message: 'Request failed',
  context: { endpoint: '/users' },
  cause: error,
});

After — message is defined once as a template, computed automatically:

const { ApiError, ApiErr } = createTaggedError('ApiError')
  .withContext<{ endpoint: string }>()
  .withCause()
  .withMessage(({ context }) => `Request to ${context.endpoint} failed`);

ApiErr({
  context: { endpoint: '/users' },
  cause: error,
});

The template function receives { name, context?, cause? } — whatever's available based on your builder configuration. You can still override the computed message at any call site by passing message: explicitly.

Context is now JsonObject

The context type constraint changed from Record<string, unknown> to JsonObject (new types: JsonValue, JsonObject). Error context must be JSON-serializable — no Date objects, no functions, no class instances. This guarantees errors survive serialization boundaries (logging, IPC, network transport) without silent data loss.

Other details

• 50 tests rewritten covering the new API surface, including a test that verifies the builder object genuinely lacks factory methods
• All 9 documentation files updated with the new pattern
• Spec doc added: specs/20260225T000000-tagged-error-redesign.md

Verification

bun test passes. TypeScript compiles cleanly. The type-level enforcement was verified by checking that createTaggedError('Foo').FooError doesn't typecheck (factories don't exist on the builder).