Retire @extrachill/api-client (post-wp-native migration)

[chubes4]

Goal

After this app migrates to consume wp-native-shell + wp-native-client (see #24, #18-#23), the @extrachill/api-client package becomes obsolete and gets retired entirely.

Why fully retire, not "slim down"

A generic framework that requires a per-site TypeScript wrapper isn't actually generic. See the wp-native principle.

Today @extrachill/api-client does two things:

1. Universal WP REST plumbing (transport, auth lifecycle, types)
2. EC-specific typed routes (client.artists.getArtist(42), etc.)

After the abilities-first migration:

1. Universal plumbing → moves to wp-native-client
2. EC-specific routes → don't get re-implemented as a typed client. They're abilities on the WordPress side, called via client.execute('extrachill/artist.get', { id: 42 }) from any consumer.

EC route knowledge lives on the server, where it belongs. No client-side duplication.

Migration order (across all consumers of @extrachill/api-client)

1. extrachill-app — replace all client.users.foo() / client.artists.foo() / etc. with client.execute('extrachill/...', args)
2. @extrachill/chat — same migration
3. EC theme blocks that import @extrachill/api-client — same migration
4. Verify no other consumers exist (grep across the platform)
5. Server-side: confirm every route currently exposed via @extrachill/api-client has a corresponding ability registered (likely already true, since EC is moving toward abilities-first across the board)
6. Delete @extrachill/api-client from the codebase
7. Unpublish @extrachill/api-client from npm (or deprecate)

Acceptance

• Zero imports of @extrachill/api-client remain across all EC repos
• All previously-typed methods now go through wp-native-client.execute()
• Package deleted from monorepo / npm

Related

• chubes4/wp-native ROADMAP M8
• Tracking issue: wp-native extraction: tracking issue #24