feat(types): support pre-typed APIs via signInteractionTrace.withTypes()

[frankieyan]

This PR adds compile-time type safety for trace names and their associated details, inspired by Reselect's withTypes pattern. This allows consumers to define their valid traces upfront and get autocomplete + error checking throughout their codebase.

Stacked on top of #8

Example

// Define your traces once
type MyTraces = {
    'open modal': { modalId: string }
    'close modal': { modalId: string }
    'submit form': { formId: string; success: boolean }
}

// Create a pre-typed sign function (recommended)
const signTrace = signInteractionTrace.withTypes<MyTraces>()

// Use throughout your app with full autocomplete
signTrace('open modal', { modalId: 'settings' })   // ✅ autocomplete works!
signTrace('opne modal', { modalId: 'settings' })   // ❌ Error: typo caught
signTrace('open modal', { formId: 'wrong' })       // ❌ Error: wrong details shape
signTrace('submit form', { formId: 'login' })      // ❌ Error: missing 'success'

// Alternative: inline type parameter (for occasional use)
signInteractionTrace<MyTraces>('open modal', { modalId: 'settings' })

// Legacy usage still works (no type checking)
signInteractionTrace('any trace name', { anyKey: 'anyValue' })

Test plan

To verify the type safety works:

1. Create a custom trace definitions type:

   type MyTraces = {
       'test trace': { id: string }
   }

2. Create a pre-typed function:

   const signTrace = signInteractionTrace.withTypes<MyTraces>()

3. Verify TypeScript catches errors:

   • Invalid trace names (e.g., signTrace('typo trace', ...))
   • Wrong payload shapes (e.g., signTrace('test trace', { wrong: 123 }))
   • Missing required properties

4. Verify autocomplete:

   • Suggests 'test trace' when typing the first argument

[doistbot-app]

This is a great addition, introducing a withTypes method to provide compile-time type safety for interaction traces. The implementation is clean and will certainly improve correctness for consumers. There appear to be a couple of type-level considerations, one that may prevent the API from checking as intended and another related to the effectiveness of a test case.