[19.0][MIG] website_*: complete analyses for 31 uncharted modules

[dnplkndll]

What

Adds upgrade_analysis_work.txt for the 31 website_ modules* that
were not yet claimed in #5363 and had only the auto-generated
upgrade_analysis.txt (no work-doc, no scripts, no umbrella entry).

The three website* modules already done in the umbrella
(website #5573, website_payment #5585, website_sale #5585)
are unaffected.

Plus one minimal post-migration.py for website_event to remap
removed menu_type selection values (location, track,
track_proposal) to the new other key, preserving existing menu
records.

Why

For each of the 31 modules: a single upgrade_analysis_work.txt
created with one annotation per non-empty analysis section, mirroring
hbrunn's style on adjacent [MIG] <module>-only commits
([MIG] bus, [MIG] http_routing, [MIG] resource_mail,
[MIG] pos_restaurant).

Most blocks annotate as # NOTHING TO DO:

• DEL ir.ui.view / DEL ir.asset / DEL ir.model.access / DEL ir.rule
  / DEL ir.actions.act_window / DEL ir.ui.menu — Odoo's standard
  upgrade flow + database_cleanup handle these (per [19.0][MIG] partner_autocomplete: cleanup obsolete res.partner/res.company fields #5631 review).
• NEW fields with hasdefault: default — Odoo populates the default.
• NEW ir.ui.view / NEW ir.asset / NEW mail.template — 19.0 module
  XML creates them on load.
• is now stored / now a function — Odoo's init_models
  recomputes/migrates on first registry init.
• module is now 'X' ('Y') — field ownership shifted between
  modules; standard upgrade flow updates ir_model_fields,
  database_cleanup handles residual ir_model_data rows.

The single # DONE block is website_event's
website.event.menu.menu_type selection_keys change. The cumulative
removal across this module + website_event_exhibitor +
website_event_track is [location, track, track_proposal];
other was added. Existing rows with the removed values get remapped
to other in post-migration so the data is preserved.

How

website_event/19.0.1.4/post-migration.py uses ORM:

```python
env["website.event.menu"].search(
[("menu_type", "in", ("location", "track", "track_proposal"))]
).menu_type = "other"
```

The three submodules that report the same selection change annotate as
# NOTHING TO DO — the data normalization happens once in
website_event.

Test plan

• pre-commit run --all-files against all changed files: clean
  (ruff, ruff-format, pylint_odoo, prettier).
• OCA CI green against the actual migration tests.

(The lab Tier 1 baseline I have locally doesn't include any of the 31
modules, so it can't validate the migration end-to-end here; deferring
to OCA CI for that.)

Companion PRs / context

• [19.0][IMP] hr: backfill NULL create_date/write_date on hr_employee #5628 (open) — [19.0][IMP] hr: backfill NULL create_date/write_date
• [19.0][FIX] loyalty: clear stale mail.template.lang referencing removed _get_mail_partner #5629 (merged) — [19.0][FIX] loyalty: clear stale mail.template.lang
• [19.0][FIX] hr: cleanup obsolete hr.employee fields from merged hr_contract #5630/[19.0][MIG] partner_autocomplete: cleanup obsolete res.partner/res.company fields #5631/[19.0][MIG] l10n_fr: cleanup obsolete res.partner.siret + orphan form view #5632 — closed per maintainer guidance; the philosophy
  applied here mirrors [19.0][MIG] partner_autocomplete: cleanup obsolete res.partner/res.company fields #5631's review (no orphan cleanup; preserve data;
  defer to database_cleanup for residuals).

Split?

Happy to split this into 5 sub-family PRs if preferred:
website_sale_* (8), website_event_* (7), website_slides_* (3),
website_mass_mailing* (2), other website_* (~11). One PR was
chosen first because the modules are largely annotation-only and the
work-doc shape is uniform across the set.