Update PAC payment status and fee wording across client surfaces

Objective

• Update pay-at-close (PAC) and related client-facing payment copy so orders do not read as fully paid until ISN reports FUNDED.
• Apply consistent PAC pending / paid language across all client- and staff-facing payment surfaces (not invoice PDF alone).
• Resolve technology fee naming after a Guardian alignment meeting scheduled over the next couple of weeks (only remaining item blocked on that meeting).

Background

• On the June 2 implementation call, Guardian reported that PAC invoices and status wording confuse clients and agents — copy can look like the order is already paid while closing is still ahead.
• Guardian also requested renaming the technology fee; the team was hesitant to adopt Guardian-only terminology without a follow-up decision.
• Triage verdict: Feature gap — PAC payment status and invoice copy exist but do not match the agreed client-facing model.
• Today, when ISN PAC reaches SIGNATURE_RECEIVED (and related success states), Attik maps payment to completed and many surfaces show "Paid" even though funding may not have occurred yet.
• Product decision (locked): Client-facing "paid" language applies only when ISN is FUNDED. Intermediate states should use non-paid / pending pay-at-close wording (exact strings TBD in internal draft).

Scope

In scope — copy / status display (all surfaces, for consistency)

• Invoice PDF: attik-backend/src/util/functions/pdf/templates/InvoiceAttachmentPDF.tsx — payment row labels and overall paid/pending headline; fee label via getFeeLabel() (currently hardcoded "Technology Fee").
• Invoice payment math context: attik-backend/src/util/functions/payments/invoicePdfPaymentHelpers.ts.
• PAC ISN → display status: attik-backend/src/util/functions/payments/pacIsnFlexFundStatuses.ts — today SIGNATURE_RECEIVED maps to Attik completed; client-facing copy must not treat that as paid until FUNDED.
• Work order payment chips: attik-frontend/src/util/functions/payments/pacStatusHelpers.ts.
• Client portal (PAC alerts, pay flows, payment history): e.g. PendingPACAlert.tsx, pay-beta / payment history components.
• Action-flow emails and any other templates that surface PAC payment status or fee names for clients/agents.

Internal draft (not blocked)

• Attik can draft proposed PAC pending/paid copy internally before the Guardian meeting.
• Only technology fee naming waits on the Guardian meeting outcome.

Out of scope

• Communication / escalation workflow (shared inbox, dedicated contact, help-doc routing, Guardian email visibility).
• Guardian card/ACH flows unless copy changes must be shared for consistency.
• ATT-1851 — unrelated to this issue.

References

• Backend: attik-backend/src/util/functions/payments/pacIsnFlexFundStatuses.ts, attik-backend/src/util/functions/pdf/templates/InvoiceAttachmentPDF.tsx
• Frontend: attik-frontend/src/util/functions/payments/pacStatusHelpers.ts

Decisions needed

Locked

1. PAC "paid" threshold — Client-facing "paid" only at ISN FUNDED. Intermediate states (including SIGNATURE_RECEIVED) use non-paid / pending pay-at-close language.
2. Surfaces in scope — All surfaces for consistency: invoice PDF, work order payment chips, client portal, payment history, and action-flow emails.
3. Guardian meeting / draft order — Draft proposed copy internally first; only technology fee naming is blocked on the Guardian meeting.
4. Communication workflow, help-docs, ATT-1851 — Out of scope for this issue.

Open (blocked on Guardian meeting, ~next couple of weeks)

5. Technology fee naming — Keep "Technology Fee", allow per-company configurable label, adopt Guardian's term for specific instances, or another approach — TBD at the follow-up Guardian alignment meeting.