Capability-gate operator chrome by camera body

[erik-sutton95]

What problem does this solve?

As a filmmaker using more than one Osmo body, I want live chrome to match what the connected camera can actually do. A gimbal joystick on Nano, Action, or 360 is dead chrome — and today the stick still mounts from chrome prefs, not from the body. The same class of leak will hit AF, FOV, D-Log2, and any future Action/360 session unless we stop writing if Nano in each shell.

Proposed solution

A portable capability table on the camera model in the Swift core. Shells (iOS + Android) mount live chrome, chrome-editor rows, and Operator Setup from those flags — not from scattered body-name checks.

First concrete gate: gimbal (stick, recenter, flip, stick throw). Pocket yes; Nano / Action / 360 / uncaptured .other no.

Alternatives considered

Keep adding “hide stick on Nano” checkboxes per issue (#83, #79, #90). That does not scale past two bodies.

Area

Live view / Camera control / UI — both shells.

Willingness to contribute

• I'd be willing to help implement this (code, design, docs, or testing)

[erik-sutton95]

Maintainer task tree:

• Parent: Gate operator chrome by camera body capabilities #124
• Core table: Core: camera chrome capability table #125
• iOS chrome: iOS: consume camera capabilities for live chrome #126
• Android chrome: Android: consume camera capabilities for live chrome #127