[16.0][OU-ADD] ptplus: keep the abandoned PT-RF CD tax tags the vendor forgot to migrate

[eantones]

Problem

At the 15→16 hop, _process_end (Odoo's orphan-xmlid garbage collector) tries to DELETE a batch of account.account.tag rows and fails:

ERROR odoo odoo.sql_db: bad query: DELETE FROM "account_account_tag" WHERE id IN (…)

Historical accounting entries and tax repartition lines still reference these tags by FK, so the delete is refused. The -u all completes (exit 0) but the wrapper turns the hop RED, and the same path is a FATAL at the 18 settle.

Root cause (archaeology, verified on ptplus 15.0/16.0/17.0/18.0/19.0)

Through 15.0, ptplus classifies PT withholding on move lines with per-payment-guide-code TAGS: PT-RF CD <code> (xmlid ptplus.tax_tag_rf_cd_*, 26 tags; the codes are the official AT guia-de-pagamento codes — 102 trabalho independente, 104 prediais, 2xx IRC… — all still officially current, so nothing was ever announced as retired).

At 16.0 the vendor rebuilds the whole RF system: dedicated withholding TAXES appear (account_tax_template_rfirs_* / rfirc_*), and from 17.0 the template CSV carries the guide code as fields on the tax (l10n_pt_wh_tax_type / l10n_pt_wh_code / l10n_pt_wh_income_type). The vendor does migrate the other tag families — migrations/16.0.5.1.0 and .5.1.2 process RF DM / M10 / M30 / IS by name filter with replace_tags()/delete_tags(), clearing the FK before the tag goes. But no filter matches PT-RF CD and the family is re-declared under no other xmlid: dropped with no data migration (confirmed: 26 in the 15.0 data, 0 anywhere in 16.0–19.0; the vendor publishes no changelog or release notes — this PR's script is, in effect, the vendor's missing migration).

Fix — selective retirement

In ptplus's own pre-migration (runs before the global _process_end):

• CD tags referenced anywhere → their ir_model_data pointer is moved to a retired namespace (__ptplus_legacy__, noupdate=true) instead of deleted: the record, every m2m link and the full original identity survive (account.account.tag has no note/comment field, so the renamed pointer itself is the provenance — visible as External ID in dev mode, queryable forever). No real module ever carries that name, so the collector never processes it.
• CD tags referenced nowhere → left alone; the collector removes them cleanly (no error, nothing lost, no zombie rows). An install with no old-system history ends up with the family fully gone.

"Referenced" = row existence in every table holding a FK to account_account_tag, discovered dynamically from the catalog — not "the delete would fail". The distinction matters: m2m rel tables with ON DELETE CASCADE would let the GC delete a tag "successfully" while silently stripping the classification off history; existence-based selection is immune.

A remap onto the new structure is deliberately not attempted: the replacement is a field on per-rate taxes (one code → many taxes), there is no tag-shaped target, and nothing at 16+ reads the CD tags (zero references in data/migrations through 19.0; no account.tax.report line ever pointed at them, verified on a real database with pre-16 history).

This replaces a data-side SQL surrogate that previously lived in the client kit's versions/16/hop/post.sql, moving the fix to the correct layer (the module's migration) and, crucially, before _process_end instead of after it.

Scope: local-only (proprietary vendor module; not an OCA candidate). Candidate for reporting upstream to Exo Software — any ptplus customer with pre-16 withholding history hits this on the 15→16 upgrade.