test(payments): pin which mint output lands in which provision field

[mahmutkaya]

The last untested seam: which mint output lands in which provision field

A pure extraction plus a five-case unit test. No behaviour change — tsc 0, eslint 0, all tests green.

The gap

openProvisioningPr could never be reached in tests: it needs a PROVISION_GITHUB_TOKEN, and
sofra-staging has none (measured — prod has the variable, staging does not). mintForProposal and
buildTenantRegistryEntry are both thoroughly tested on either side, but the five lines that decide WHICH
of the mint's three outputs lands in WHICH field sat inline between them:

const withAccount: TenantProvisionInput = {
  ...input, partnerBrand,
  ...(mint.stripeAccount ? { stripeAccount: mint.stripeAccount } : {}),
  ...
};

stripe_account: receiving a URL is a registry entry that provisions a tenant pointed at an account that
does not exist — and nothing downstream would notice, since provision-tenant.sh checks the pairing, not the
shape.

The fix

applyMintToProvisionInput (lib/provisioning-mint.ts) — pure, so the mapping is testable without a token.
The conditional spreads are deliberate: buildTenantRegistryEntry distinguishes an absent key from one
present-and-undefined, so { stripeAccount: undefined } can emit a blank stripe_account: line that
provision-tenant.sh reads as configured-but-empty.

Measured with two mutants, both landed and compiled first

mutant	result
stripeAccount and paymentsLinkUrl swapped	2 tests red
the key always present (stripeAccount: mint.stripeAccount as string)	2 tests red

Assertions are field-by-field rather than toEqual on the whole object, because a swap is exactly the failure
being guarded and toEqual does not name which pair moved.

Context

The e2e proof of this chain lives in #238 (tests/e2e/connect-mint.spec.ts), which needs only the Stripe test
key. openProvisioningPr itself still needs a PROVISION_GITHUB_TOKEN to be exercised — see BACKLOG, "The
MINT half now runs end to end".

---

REVIEW PROVENANCE. The gate's claude CLI is org-blocked ("Your organization has disabled Claude's subscription access"), and the documented GLM fallback cannot drive it (GLM + --tools "" stops on tool_use, unparseable verdict — twice). Per the owner's instruction, this diff was reviewed by the parent agent (glm-5.3-flash) against the gate's own prompts: pure extraction, conditional spreads deliberate, two mutants red on exactly the right assertions, positive control present. RUMI_REVIEW_FAIL_OPEN=1 was used for this push only, with the substantive review done as above. CI + threads + Sonar still enforced by the merge gate.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud