Adopt auto-generated TypeScript clients from OpenAPI spec

[scotwells]

Summary

The search service uses openapi-ts to auto-generate TypeScript clients from its OpenAPI spec, while activity manually maintains TypeScript types in ui/src/types/. We should evaluate aligning on the auto-generated approach for consistency and reduced maintenance burden.

Current State

Activity (manual types):

• Hand-written TypeScript types in ui/src/types/activity.ts, ui/src/types/policy.ts, etc.
• Types must be manually kept in sync with Go API types
• OpenAPI uses default naming (with ~1 URL encoding for slashes)

Search (auto-generated):

• Uses openapi-ts to generate TypeScript clients from OpenAPI spec
• Uses ToRESTFriendlyName for clean schema names (dots instead of ~1)
• Types automatically stay in sync with Go API changes

Required Changes

If we adopt auto-generation:

1. Add ToRESTFriendlyName to OpenAPI config in cmd/activity/main.go:

   genericConfig.OpenAPIV3Config.GetDefinitionName = func(name string) (string, spec.Extensions) {
       friendlyName, extensions := namer.GetDefinitionName(name)
       return openapiutil.ToRESTFriendlyName(friendlyName), extensions
   }
   genericConfig.OpenAPIV3Config.Definitions = nil  // Force re-computation (see datum-cloud/search#64)

2. Add openapi-ts generation to the build pipeline

3. Replace manual types in ui/src/types/ with generated ones

Trade-offs

Pros:

• Single source of truth (Go types)
• Types always in sync after code generation
• Consistent approach across services
• Less manual maintenance

Cons:

• Generated types may need wrapper types for UI-specific concerns
• Additional build step dependency
• Migration effort for existing UI code

References

• Search PR implementing the fix: fix: resolve OpenAPI spec $ref naming mismatch search#64
• ToRESTFriendlyName converts go.miloapis.com~1activity~1... → com.miloapis.go.activity...