fix: address code-review follow-up nits (confirm-stamp ordering, gate error classification, guest remap scope, RG existence check)

[Gregory Joseph (gnjoseph)]

Four LOW-severity follow-up nits from the PR #3 review — each small, surgical, and low-risk. Full pipeline green (lint / typecheck / build / test), 731 passed | 3 skipped.

The 4 nits

1. Stamp confirmed BEFORE billing elicitation (src/tools/provision.ts) — robustness

Previously the session was stamped confirmed only after the owning app was resolved, which ran after the billing-model / sub-RG elicitations. If the agent dropped appSelection while answering a later billing prompt, the always-ask app gate could re-fire.
Fix: stamp the confirmation flag as soon as the owning app is settled (right after the app gate, before any billing/sub-RG elicitation can return-and-reenter). The ownerScope gate is relaxed to key on resolved intent only (arg ?? state) — not session confirmation — so the earlier stamp doesn't suppress its ask. The confirmBilling financial-safety gate ordering (guided sub/RG → region check → confirmBilling → createSyntexAccount) is unchanged, and the app-gate always-ask semantics are preserved.
Test: orchestration.test.ts — app settled + a subsequent billing round-trip that omits appSelection does NOT re-return the app-selection ask.

2. Move context gate inside the handler try (control-plane mutation tools) — error classification

resolveContextGate(contextChoice) on confirm calls stampContextConfirmed→writeState→writeSecureFile, which can throw (EACCES/EIO). The gate was called above each handler's try, so a stamp-write failure surfaced via the generic dispatch catch instead of the tool's own classifier.
Fix: moved the gate inside the existing try (still before the tool's main work) in create-container-type.ts, register-container-type.ts, container-type-app-grants.ts (add + remove), and container-type-permissions.ts (owner grant + revoke). Early-return-on-gate behavior is identical.
Test: gate-error-classification.test.ts — with writeState mocked to throw, every gated handler called with contextChoice=confirm returns its own classified isError result (not an unhandled throw).

3. Scope the guest-owner error remap to the self-target path (src/tools/container-type-permissions.ts)

isGuestOwnerRejection(e) remapped any Graph error mentioning "guest"/"#ext#" to guest guidance — so an explicit member userId grant failing for an unrelated "guest"-containing reason got misdirected guidance.
Fix: apply the guest-owner-rejection remap only when the target is the signed-in user (default self-target). Explicit-userId failures surface the raw reason(e). The proactive userType === "Guest" self-target check is unchanged.
Test: container-type-tools.test.ts — explicit member userId failing with a "guest"-containing message → raw reason surfaced (NOT guest guidance); self-target guest rejection → guest guidance (existing behavior preserved).

4. Verify a user-entered new resource-group name (src/tools/standard-billing-target.ts) — fail cost-free

On the 0-RG path the helper prompted for a NEW RG name and proceeded unverified; a typo/non-existent RG only failed later at createSyntexAccount — after the container type existed. The server cannot create the RG.
Fix: added a non-throwing resourceGroupExists(name, subscriptionId) helper (src/azure-cli.ts, az group show) and probe the entered name. If it definitively does not exist → return actionable guidance (az group create ... then re-run) and fail cost-free before any CT/billing resource is created. An indeterminate probe (az missing / auth / transient) degrades gracefully to the prior behavior (proceed). Auto-select-singleton and multi-RG elicit paths are unchanged.
Test: standard-billing-target.test.ts (unit: missing → guidance/does-not-proceed; exists → proceeds/verified; indeterminate → proceeds/unverified; singleton + multi paths never probe) and provision-guided-billing.test.ts (integration: 0-RG + missing entered name → cost-free guidance, createApplication/createContainerType/createSyntexAccount NOT reached).

Guardrails honored

• No change to the confirmBilling gate ordering, the app-gate/session core, or any tool names/schemas.
• No internal refs (cites "PR Initial import: SharePoint Embedded MCP Server #3 review" only); no secrets; MIT header on both new files.

Local pipeline

npm run lint ✓ · npx tsc --noEmit ✓ · npm run build ✓ · npm test → Tests 731 passed | 3 skipped.