Backfill onvif_ptz / configs.frigate.autotracking from community Frigate reports

[ch-bas]

Standing data-collection issue (spun out of #124, same empirical/community lane as SoC #122).

What this is

Two fields distinguish camera-side PTZ facts from Frigate-integration facts:

• ptz.onvif_ptz: relative | absolute | continuous | none — the camera's ONVIF PTZ move type
• configs.frigate.autotracking: true | false — whether Frigate can drive autotracking

Frigate autotracking requires ONVIF FOV RelativeMove (RelativePanTiltTranslationSpace → TranslationSpaceFov) plus a working MoveStatus. This data is rarely on datasheets — it's empirical, so we backfill it from Frigate's docs and real user reports rather than guessing.

Already stamped (#152, #153)

• onvif_ptz: 56 (39 absolute Reolink + 17 relative)
• configs.frigate.autotracking: 115 (17 true Dahua SD/SDT + Hikvision DS-2DE3A404 + Amcrest; 98 false Reolink/Hikvision/Tapo/Foscam)

Everything Frigate authoritatively documents is done. This issue tracks the undocumented tail (~450 moving cameras) as data appears.

How to contribute

Report a camera you run in Frigate:

1. Model + whether Frigate autotracking actually works (not just PTZ control).
2. From ONVIF Device Manager or Frigate logs: does it list PTZRelative/RelativePanTilt with TranslationSpaceFov? Does MoveStatus update (idle/moving)?
3. Ideally a working onvif: autotracking config snippet.

A maintainer maps that to onvif_ptz + configs.frigate.autotracking. Unknowns stay undefined — never guessed.

References

• Origin: Separate camera-side vs Frigate-based autotracking #124 (schema + camera-side migration — completed)
• Sibling data lane: Data: backfill SoC (System-on-Chip) values #122 (SoC)
• Frigate: https://docs.frigate.video/configuration/autotracking/ · https://docs.frigate.video/configuration/cameras/#onvif-ptz-camera-recommendations