Revenue canonical Platform Person name sync is live

Revenue implemented and deployed the requested provider correction. Final production commit b2dd2f3 is READY in deployment dpl_3CV8wbpUT1Sg7WwDT8dhWV29wdfb at https://revenue-bigiw3urw-jack-allreds-projects.vercel.app. It owns the https://revenue.sguildswim.com production alias. Vercel's build record confirms the production artifact was cloned from main at b2dd2f3, and the post-deploy error-log scan was clear.

The earlier f5900d0 artifact attempted a direct Platform Person read. Revenue superseded it after preflight found that Platform's current Person GET is human-session authenticated and Revenue has no service credential for that route. No real customer invoice or provider repair was run against that artifact.

Provider behavior

ensureSquareCustomerBridge now gives the submitted payer_name or customer_name operation snapshot precedence over Revenue Client.fullName when synchronizing the Square customer. Sales asserts that it loaded the snapshot from the canonical Platform Person immediately before invoice submission. A stale nonblank Revenue Client name can no longer override it. When no request name is supplied, Revenue preserves the existing Client-name fallback for non-Sales callers.

Revenue did not add a competing identity writer. The request snapshot remains operation-scoped and is used only for provider customer synchronization. Revenue amended sales-ordering-surface to v2.5.1 so this precedence is contractual rather than implicit. The invoice-link payer_name follows the same rule.

Both requested invoice paths already call this shared bridge:

• add-on and top-up invoice-link, POST /api/v1/orders/invoice-link
• first-lesson reserved invoice, POST /api/v1/sales-ordering/close

Regression coverage proves the bridge chooses the submitted canonical Person snapshot over a stale nonblank Revenue name, preserves the Revenue fallback when the snapshot is absent, exercises the invoice-link route, and confirms the first-lesson close passes its current customer name into the reserved invoice issuer. Revenue typecheck passed. The full suite passed 70 test files and 432 tests. The focused invoice surfaces passed 51 tests.

Existing open invoice repair

This deployment corrects future invoice-time customer synchronization. It does not rewrite the recipient snapshot on an invoice that Square already generated. Revenue has not changed any real customer or provider invoice as part of this implementation.

For an already-generated open invoice, Revenue needs the exact Revenue client, Order, Order External, or Square invoice id plus explicit operator authorization. Revenue will then preflight the canonical Person, Revenue bridge, Square customer, and unpaid open invoice. If the target still matches, Revenue will synchronize the Square customer, cancel the open invoice through the existing guarded cancel workflow, and regenerate the invoice so the new invoice captures the corrected canonical name. A paid, canceled, mismatched, or otherwise changed target will fail closed and return for operator review.