Button wrappers: align legacy button-specific props (success/danger → variant) in ConfirmModal & FormAlertWithSubmitButton

[MelvinBot]

Sub-issue of #83762.
Migration plan: Guccio163 comment.

Background

The composed Button collapsed several legacy config props into new conventions — success/danger booleans → variant="success"/variant="danger", small/medium/large → size, shouldBlendOpacity → blendOpacity, etc.

The sub-issue for ButtonWithDropdownMenu's public API alignment (#95179) is done, and BaseWidgetItem's buttonProps → buttonVariant collapse is handled in #98878 / PR #98861. This issue does the same public-API alignment for the remaining Button wrappers that still expose legacy button-specific props and still render the old @components/Button internally.

This is the "fuller alignment" the plan flagged as a separate decision (reference): renaming a wrapper's own public props to the composed conventions, which ripples to that wrapper's callers.

Scope

1. ConfirmModal → ConfirmContent

• ConfirmContent.tsx still imports the old ./Button and renders <Button success=... danger=...> (L251-L290).
• Both ConfirmModal.tsx and ConfirmContent.tsx (L51-L55) expose their own public success?: boolean / danger?: boolean props.
• Change: collapse the wrapper's public success/danger → a single variant prop and migrate ConfirmContent's internal <Button> to @components/ButtonComposed.
• Blast radius: ConfirmModal is referenced by ~167 files; only the callers that actually pass success/danger (~16 files) need updating.

2. FormAlertWithSubmitButton

• FormAlertWithSubmitButton.tsx still imports the old ./Button and forwards the legacy button-specific concepts under differently-named props:
  • isSubmitActionDangerous → danger (L55, L161/L179)
  • useSmallerSubmitButtonSize → medium/large (L73, L162-L163/L180-L181)
  • shouldBlendOpacity → shouldBlendOpacity (L88)
  • hardcodes success on the internal Button (L156/L170)
• Change: migrate the internal <Button> to @components/ButtonComposed (variant/size/blendOpacity). Decide per-prop whether to align the public API (e.g. keep isSubmitActionDangerous/useSmallerSubmitButtonSize as domain-meaningful names vs. renaming) — favor mapping to composed conventions internally while keeping the public names that read well at call sites, matching the plan's guidance.
• Blast radius: ~45 caller files.

Not in this issue (already handled): ButtonWithDropdownMenu (#95179, done), BaseWidgetItem (#98878 / PR #98861). SettlementButton, AnimatedSettlementButton, AnimatedSubmitButton, and FloatingGPSButton already use the composed API. AddToWalletButton wraps the native wallet button, not our Button.

Migration rules

Follow the established prop-change rules and mirror the approach used in #95179:

• success / danger (wrapper public + internal) → variant="success" / variant="danger" (CONST.BUTTON_VARIANT)
• small / medium / large → size={CONST.BUTTON_SIZE...}
• shouldBlendOpacity → blendOpacity
• Internal @components/Button → @components/ButtonComposed
• Update every caller that passes a changed prop.

Acceptance criteria

• ConfirmModal/ConfirmContent public success/danger collapsed to variant; ConfirmContent renders @components/ButtonComposed.
• FormAlertWithSubmitButton renders @components/ButtonComposed; its forwarded button-specific props map to composed conventions.
• No remaining @components/Button import in the two wrappers (ConfirmContent, FormAlertWithSubmitButton).
• All affected callers updated (ConfirmModal callers passing success/danger; ~45 FormAlertWithSubmitButton callers).
• eslint-seatbelt count reduced accordingly.
• No visual regressions in confirm modals and form-submit footers (variant color, size, disabled/loading, press).

Dependencies

• Blocked by batch 1: the deprecation guard must exist before merge.
• Can run in parallel with the remaining migration batches.