Revisit Portainer registry buildup after Home Assistant startup guard fix

## Why revisit this

Home Assistant Core 2026.8.3 failed to finish startup after its finite entity-registry restore exceeded the 10,000 queued-event dispatch guard.

The official Portainer integration was the enabling condition:

- 6,891 Portainer entity-registry records
- 6,720 container entity records across 627 historical container devices
- only 63 containers reported by the live Portainer coordinator
- 13,468 enabled Home Assistant registry entries before recovery

This matches the Home Assistant Core failure tracked in:

- https://github.com/home-assistant/core/issues/177249

The current Portainer coordinator prunes departed containers from its in-memory tracking set, but the historical entity/device registry records require separate review.

## Current status

Cleanup completed on 2026-08-29 after verified Home Assistant, MariaDB, and registry backups:

- 5,667 confirmed-stale entity records removed through the supported registry API
- 561 confirmed-stale container devices removed through the supported device API
- 1,224 Portainer entities remain; 69 useful/current entities are enabled and 1,155 are disabled
- 104 Portainer devices remain: 5 endpoints, 66 containers, and 33 retained volumes
- 8,493,557 historical state rows and 6,826,666 statistics rows removed
- exact post-restart audit shows zero Portainer recorder state/statistics rows
- raw Portainer telemetry excluded from recorder/logbook; aggregate Docker health and curated events retained
- Home Assistant configuration valid and controlled restart healthy
- 55 monitored containers, 0 unavailable, telemetry degradation off

Three moved-container device shells remain because the Portainer integration rejected their supported removal requests. Startup also reports duplicate unique IDs for a small set of same-named containers across endpoints. The 33 volume devices remain because current diagnostics do not prove they are stale.

Tugtainer and the owning Compose stacks remain authoritative for container update decisions; duplicate per-container Portainer image-update controls stay disabled.

Full cleanup evidence: https://github.com/CCOSTAN/Home-AssistantConfig/issues/1917#issuecomment-5464926735

## Revisit checklist

- [ ] Follow `home-assistant/core#177249` and identify the first stable Home Assistant release containing its fix.
- [ ] Check for, or file, an upstream Portainer-integration issue covering stale entity/device cleanup, rejected device removal, and cross-endpoint unique-ID collisions.
- [ ] Confirm the installed Portainer integration no longer grows registry records when containers are replaced or removed.
- [x] Capture a current backup before registry cleanup.
- [x] Compare current Portainer coordinator inventory with registry-owned devices and remove only confirmed stale records through supported Home Assistant APIs.
- [x] Re-enable only useful, current Portainer telemetry; keep duplicate image-update controls disabled.
- [x] Run the repository configuration check.
- [x] Perform a controlled Home Assistant restart and verify it reaches `RUNNING` without the 10,000-event/endless-loop error.
- [ ] Verify registry counts remain stable through at least one later container-update cycle.

## Closure criteria

Close this after the upstream Core guard fix is installed, the remaining Portainer identity/cleanup defects are resolved or accepted upstream, and a later container-update cycle completes without registry growth or startup failure.

Start by following home-assistant/core#177249 to identify the first stable release with the startup-guard fix, then review the Portainer integration's registry cleanup and identity behavior. Use the completed cleanup evidence and the revisit checklist as the baseline; done means a later container-update cycle completes without registry growth or startup failure, with remaining defects resolved or accepted upstream.

Written by the indexing model from the issue text.