Add a pluggable tax/invoice service seam (calculation, evidence, invoice reference), keeping tax engines out of core

Design for this, resolving the open questions in the summary:

Interface: three explicit methods

• calculate($subscription, array $lines, $period_start, $period_end): TaxResult — pure and side-effect free; safe to call repeatedly. The lines are the period's RatedLines (#3615735: Add a rating step for usage-based charges, delivered per connector scheduling mode), with the engine representing the base fee as a line too, so the tax engine always sees the whole basket.
• recordCharge($charge): ?string — side-effecting: registers a succeeded charge with the tax system and returns the invoice reference, or NULL when nothing was issued (the null implementation always; a bridge may also decline, e.g. for a zero-amount period).
• recordRefund($charge, string $amount): ?string — the refunds question from the summary, decided: a dedicated method rather than a negative-amount convention. Explicit beats sign conventions, and the #3619074: Succeeded charge records are terminal, so payer-initiated reversals (SEPA refunds, Bacs indemnity claims, chargebacks) have nowhere to land reversal work needs a credit-note path with its own semantics anyway. Returns the credit-note reference.

Evidence: deliberately not modeled upstream

The summary asks for the evidence structure; the answer is that upstream should not have one. A bridge (Quaderno first) gathers and retains location evidence itself from what the site knows — billing address, IP, VIES validation — because evidence requirements are jurisdiction- and provider-specific: exactly the maintenance liability the issue's problem statement keeps out of this module. Upstream passes the subscription (hence the account) and the money; everything else is the bridge's domain.

Inclusive/exclusive semantics

TaxResult carries a mode and a list of TaxLines (label, rate, amount). With exclusive treatment the engine adds the tax total to the period charge; with inclusive treatment the amount is unchanged and the lines are informational (the tax is inside the price). Either way the lines and mode are recorded in the charge record's data map alongside the rated lines, so the full breakdown is auditable per charge.

Wiring: one service slot, null by default

A single service (subscription_manager.tax_invoice) rather than a collector — a site has exactly one tax authority. The shipped default is a NullTaxInvoiceService (no tax, no invoices, NULL references); a bridge module replaces the class via a ServiceProvider. The cycle engine calls calculate() when computing the period amount and on upgrade proration (tax applies to prorations too), recordCharge() in the single charge-success path, and recordRefund() on refund success. For self-scheduling connectors the hand-off stays documentation on the interface: their webhook handlers call recordCharge() when the remote service settles a charge, so remote-generated invoices register identically.

Storage and scope

New invoice_reference string field on the charge entity (queryable, exposed to Views) with an update hook; credit-note references and any richer bridge payloads go in the data map. The member-facing invoice list in the portal is deferred to its own follow-up issue — it is UI on top of the stored references and should not gate the Phase 4 work that builds on this seam. Tests: a state-controlled test double exercising both modes, recorded references, refund recording, and the null default leaving behavior byte-identical.

Implemented in the MR, per the design in #3, in two commits.

The seam. TaxInvoiceServiceInterface — a single service slot (subscription_manager.tax_invoice), shipped as NullTaxInvoiceService, replaced by a bridge via ServiceProvider (the test module's own provider demonstrates the mechanism). Three methods: calculate() (pure; the basket is the base fee as a normalized line plus any rated usage lines from #3615735: Add a rating step for usage-based charges, delivered per connector scheduling mode, the answer a TaxResult with inclusive/exclusive treatment and as many TaxLines as the jurisdiction stacks — Canadian GST + PST land as two lines), recordCharge() (returns the invoice reference, stored in the new invoice_reference charge field, installed by update 10020 and exposed to Views), and recordRefund() (the dedicated credit-note method decided in #3; references append to data['credit_notes']). Location evidence is deliberately not modeled, per #3.

Engine wiring. calculate() runs while computing each period amount and on upgrade prorations — exclusive tax is added on top (and reaches the connector in the charged amount), inclusive tax is recorded without changing the amount; lines and mode land in the charge data map next to the rated lines. recordCharge() fires everywhere a charge reaches succeeded: the synchronous path, webhook resolution of pending charges, and the settled-locally zero path (whether a zero period deserves an invoice is the implementation's call). recordRefund() fires on refund success. The self-scheduling hand-off is documented on the interface: webhook handlers call recordCharge() when the remote service settles a charge.

Also fixed in passing: both charge-failure paths used to overwrite the charge's data map with the failure message, clobbering the rated (and now tax) lines; the message now merges in, with regression tests for both paths.

Tests. New TaxInvoiceTest (ten scenarios) driven by a state-controlled TestTaxInvoiceService that defaults to null-service behavior, so the rest of the suite doubles as the no-tax regression check. Suite is at 100 kernel tests / 1257 assertions; update 10020 verified on a live site.

Change record drafted. As scoped in #3, the member-facing invoice list is a separate follow-up issue, and the Quaderno bridge gets filed as its own project once this lands.