l10n_fr_einvoicing: add data/neutralize.sql — a production dump restored on a test database keeps live credentials and active crons

[risto42]

Branches concerned: 16.0 AND 18.0 (the per-module neutralize framework is identical in both — odoo/modules/neutralize.py; the very same file can be committed to both branches).

Standard workflow: production databases are regularly dumped and restored onto test/dev databases. With this module configured in production, the restored copy keeps:

• fr_ctc_client_id / fr_ctc_client_secret on res.company — and running_env does not protect: it only switches superpdp_company_number_scheme to sandbox (res_company.py), the API URL is the same, so production credentials authenticate from anywhere;
• the crons (fr_einvoicing_flow_in/out_cron, fr_directory_update_cron) in their production state (active).

First server start on the copy: flow_in fetches real inbound flows and — with fr_ctc_event_auto_send_in_hand/approved — sends real lifecycle events to real suppliers; flow_out can emit real invoices from a test database.

Base neutralization (db load -n / odoo-bin neutralize) already deactivates all crons and mail — but the module's configuration survives it: a manual "send via platform" click still emits for real, and if a cron is re-enabled for sandbox testing, _cron_companies() selects companies on fr_ctc_accredited_platform + fr_ctc_auth_method (not on credentials), so the production company is picked up again.

Three complementary suggestions:

1. a data/neutralize.sql in l10n_fr_einvoicing clearing fr_ctc_client_id, fr_ctc_client_secret and fr_ctc_accredited_platform on res_company (same spirit as the core's mail neutralization) — sparing companies whose SIREN is in SUPERPDP_SANDBOX_SIREN, so a sandbox-connected test database survives neutralization (sandbox credentials are harmless by construction).
2. structurally: an optional l10n_fr_einvoicing_environment module (same pattern as OCA mail_environment) making the credential fields server.env.mixin-backed — each environment carries its own credentials in its config file (prod = real, dev = sandbox), nothing sensitive ever lands in a dump. Given Akretion's history with server_environment, this seems like a natural fit.
3. alternatively (mentioned as a possibility): since the module already reads running_env for the directory scheme, it could make it genuinely protective — e.g. refuse outbound emission/API calls with real credentials whenever running_env is dev/test.