Bug: popup checkout keeps stale totals after valid EU VAT validation (2.2.0)

TL;DR: EU VAT validation succeeds and the server removes VAT, but the native popup keeps displaying the previous price and VAT breakdown. Reproduced on an isolated staging site with Core + Pro 2.2.0, including with our relevant customizations disabled. No live payments were involved.

HOW TO REPRODUCE

• Use a digital product priced at €67 including 21% VAT (€55.37 base + €11.63 VAT).

• Open the native modal checkout.

• Select another EU country and validate a genuinely valid VAT number through VIES.

ACTUAL RESULT

• VAT validation succeeds: the field is marked valid and becomes read-only.

• The server cart correctly contains €0 tax and an estimated total of €55.37.

• The popup product card and summary still show €67 and the previous 21% VAT.

EXPECTED RESULT

The product card, tax breakdown and total should all refresh immediately to the same €55.37 amount, with the reverse-charge treatment clearly reflected.

TECHNICAL FINDING

TaxModule::handleVatValidation() returns a fragment for [data-fluent-cart-checkout-page-cart-items-wrapper], which does not exist in the modal. The modal instead uses [data-fct-modal-checkout-summary] and [data-fct-modal-checkout-summary-group]. Our temporary adapter refreshes those two fragments using the native renderer, without changing tax calculations or editing Core. This resolves the display mismatch in our test.

RELATED PRESENTATION ISSUE

The modal also did not visually strike through the original tax badge marked .is-reversed. Please check that the reverse-charge styling is loaded consistently in the popup.

We have separately reported that zero-rate territorial overrides do not display their fiscal reason in checkout/invoices. That is a different issue: here the immediate problem is a stale visible total after successful VAT validation.

Could you confirm and fix the native modal fragments? We would prefer to remove our temporary compatibility adapter rather than maintain checkout fixes long-term. We have not tested a payment with the stale VIES summary, so this report does not claim that the wrong amount was charged.

For reference, our separate native VAT/refund Revenue report is already tracked here, so I am not duplicating its reproduction in this post:
https://community.wpmanageninja.com/portal/space/fluent-cart/post/full-refund-still-leaves-negative-revenu