Stack v5 menu leaf presentation and application-owned action state

[juliusmarminge]

Stack v5 header menus distinguish one-shot actions from native tracked toggles. I would like to expose three missing leaf-item presentation properties on StackHeaderMenuItemIOS:

subtitle?: string;
disabled?: boolean;
destructive?: boolean;

A generic document menu can explain an unavailable operation with subtitle: "Select a document first" and disabled: true, and mark a delete operation with destructive: true. Today those keys are rejected by the native dictionary mapper. The proposal applies to both effective action and toggle items because both render as native menu leaves. Omission resets subtitle to absent and both attributes to false. Attributes must compose with keepsMenuPresented, and imperative title/icon/toggle updates must preserve them. It adds no behavior to Android's separate menu definition.

This differs from #4620, which disables the header button itself. It should also work when the same menu definition is used by #4587's overflow representation.

A separate question concerns application-owned action state:

state?: 'off' | 'on' | 'mixed';

For example, a formatting action can display mixed when the selected documents have different settings. It should still invoke onPress, and its application chooses the next state. Existing setMenuItemOptions({ toggleState: true }) already solves external control of native on/off toggles and single-selection groups. It intentionally ignores actions and cannot express mixed state. I propose state only for items whose effective type is action, ignored for effective toggles. It would default/reset to off, remain unchanged by a tap, and be available through the existing item-options command, rather than adding a second toggle-control mechanism.

These map to standard native menu presentation and selection-state concepts. Native references: menu attributes, subtitle, and mixed state.

I plan focused PRs with a FabricExample scenario that exercises disabled taps, callback separation, stable-ID rebuilding, command preservation, and removal/reset. The state change can be reviewed separately. For React Navigation, the v5 adoption draft is #13115; I will prepare a companion against that draft because main has no v5 adapter yet.

Does this division fit the intended v5 menu API? In particular, should action-owned state stay distinct from the library's tracked toggle state as described above?