fix(provisioning): a Management API consumer's first run is one file, one apply

[windischb]

Summary

Reported from the field by a Management API consumer (amZettel) with the standard first manifest: a role on the system app, a service account with a credential, and a group binding the two — handles throughout. Three things stood in the way. None of them was the apply; two were the plan lying and one was the section order.

#	Symptom	Cause	Fix
1	"#mgmt-sa" in a group's Members refused up front as Manifest.HandleAppliedTooLate	Service accounts applied after groups. A credential only references apps and scopes, both applied earlier.	Service accounts now apply before groups, like users. The plan already listed sections in that order; applier and order check agree now.
2	Re-planning an export announced Member 'x' — this realm has no such entity on an unchanged group; the id-only spelling of the same member read as an update	The planner canonicalized and resolved Members against users only, while the exporter writes a service-account member as { Key, Id } like any other	Members resolve against users, nested groups and service accounts — the three kinds the applier's member resolver has accepted since the always-staged wave
3	A role on modgud announced as the apply SKIPS this role entirely. Import the app first — while the apply created it fine	The planner took its app catalog off the export, which leaves the system app out on purpose; the applier's resolver is seeded from the live query	The plan reads the realm's apps live, as the apply does. Same fix covers a client, API or scope pointing at the system app.

The Management API permissions (oauth-authorization:*, app-scope:read, position:read, …) live on the system app, so #3 hits every consumer of the surface #236 added.

Not changed

• resource= on the device-authorization endpoint is rejected with invalid_target although RFC 8707 §2 allows it there. A separate OAuth item, not the planner.
• The ClientSecret is ignored for an existing client plan note stays: it is the honest signal that the file carries dead weight.

Test plan

• A_management_api_consumer_provisions_role_service_account_and_group_in_one_run — plan without a manifest error or a phantom note, apply lands role + account + group + membership in one run, export re-plans as unchanged and note-free, id-only member spelling is the same membership. The field report is the red run on the released build.
• Existing order test (A_handle_that_cannot_honour_its_promise_is_refused_or_reported) still green — positions still apply after groups.
• Full backend suite green (835 integration + 1668 unit)
• CI on this PR

🤖 Generated with Claude Code