Fix/473 quarantine noupdate

[LunarCapsule127]

Why is this change needed?

data/quarantine_cron.xml declared two crons and two config params in a plain <odoo> block with no noupdate, so every module upgrade rewrote all four to the shipped defaults. An admin who tuned a retention window, changed a cron interval, or deliberately disabled a cron got silently reset on the next upgrade.

Split out of the #470 review, which fixed the same defect in scan_sweep_cron.xml.

Fixes #473.

How was the change implemented?

1. Wrapped quarantine_cron.xml in <odoo noupdate="1">.
2. Added migrations/19.0.2.2.0/post-migrate.py, since the loader only honors noupdate at record-creation time; on databases that already installed the module, the four ir.model.data rows exist with noupdate = False and the XML change alone would not flip them. The migration sets noupdate = TRUE on those rows and leaves the stored values untouched, so tuned values survive and untouched defaults stay as shipped.
3. Bumped the manifest to 19.0.2.2.0 so the migration runs.

New unit tests

None added; extended the existing regression test.

Unit tests executed by the author

No local environment; relying on repository CI to run spp_attachment_av_scan tests on this PR.

How to test manually

1. Install the module, then change one of the quarantine params (e.g. set spp_attachment_av_scan.quarantine_retention_days to 30) or disable one of the crons.
2. Upgrade the module.
3. Confirm your change survives instead of snapping back to the shipped default.

Related links

• Extends feat(spp_attachment_av_scan): sweep attachments stranded at pending scan #470
• Closes spp_attachment_av_scan: quarantine_cron.xml crons/params are not noupdate — upgrades silently reset admin-tuned values #473