M7.2.8: keep register + OAuth flows on REST for v0.1 (defer to post-v0.1)

[chubes4]

Scope

Decision document — no code changes in this issue.

Per the EC abilities audit, three EC auth flows do NOT migrate to wp-native-auth in v0.1:

Flow	Why it stays on REST
api.auth.register	Turnstile + invite tokens + community provisioning are EC-specific. Not in wp-native-auth scope.
api.auth.loginWithGoogle	OAuth strategy deferred — see wp-native#18
api.auth.getOAuthConfig	Same — supports the Google flow above

These continue calling extrachill/v1/auth/register, /google, /config/oauth REST routes via the existing extrachill-users endpoints.

What this means for the app

After M7.2.3-M7.2.7 land:

• Email/password login → wp-native/auth-login (universal)
• Logout → wp-native/auth-logout
• /me → wp-native/auth-me
• Refresh → wp-native/auth-refresh (automatic via AuthFetchTransport)
• Browser handoff → wp-native/auth-browser-handoff

But:

• Register → extrachill/v1/auth/register (REST, unchanged)
• Google OAuth → extrachill/v1/auth/google + /config/oauth (REST, unchanged)

The app will need to keep a small REST client for these three endpoints. Easiest path: keep @extrachill/api-client installed, just use it for these three calls. The full retirement happens in M8 — by then wp-native-auth will have OAuth abilities and EC will register a extrachill/auth-register ability.

Acceptance

This is a decision-tracking issue. No code changes. Closes by being merged into M7.2.9 (the final cleanup PR) which documents the v0.1 boundary.

Follow-ups

• chubes4/wp-native#18 — OAuth strategy decision
• A future EC issue: register extrachill/auth-register ability for the registration flow

References

• Audit
• Tracking #27