fix(accounts): survive an auth plane older than the SDK's principal schema

[pyramation]

Summary

Listing principals crashed against a real endpoint:

Cannot query field "useAdminOwner" on type "Principal".
Cannot query field "isActive" on type "PrincipalScopeOverride". Did you mean "isAdmin"?

Those three fields are declared by @constructive-io/sdk's generated types — the published package is generated from a newer schema than the auth plane being talked to, so the types promise fields the server has never heard of. Nothing on this side can type-check that away; the drift is between the package and the deployment.

So the query asks optimistically and degrades:

try { return await read(PRINCIPAL_SELECT); }        // every field
catch (e) {
  if (!missingField(msg)) return rethrow(...);      // a real failure stays a failure
  return await read(PRINCIPAL_SELECT_CORE);         // the fields every vintage has
}

missingField matches only Cannot query field, deliberately narrow: a STEP_UP_REQUIRED or a permission error must not be retried as if it were drift (and the retry re-throws properly, so a second failure isn't swallowed).

Losing isActive/useAdminOwner costs detail, not correctness — their absence already means inherited, which is exactly what readPrincipal defaults them to. createOrgPrincipal now omits useAdminOwner from the input rather than sending it as null, for the same reason: don't ask an older server about a field it doesn't have.

Link to Devin session: https://app.devin.ai/sessions/04636534e07048089ffb6b78142e12cd
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring