Subscriptions: unbuilt controls and the swipe colour rule #1276

Problem or use case

The Subscriptions design pass in #1269 brought the screens in line with Bitkit - Handoff v62, but deliberately left four things out because each needs a product or design decision rather than a rendering fix. Three are controls the handoff draws that neither platform has built; the fourth is a colour rule the design system implies but the frames do not commit to.

None of these are regressions — all are absent on iOS as well as Android, so they are unbuilt design, not drift. Recording them here so they are not silently lost now that the surrounding screens look finished.

Proposed solution

1. Edit on the created-subscription detail
The handoff footer is Edit + Delete (Subscription Detail Created); the app shows Delete only. Needs a decision on what is editable after a subscription exists — amount and frequency change what the payer already accepted, so this may mean re-proposing rather than editing in place.

2. Renew on the expired detail
The handoff footer is More Info + Renew (Subscription Detail Expired); the app shows More Info only. A renew entry point implies a re-subscribe flow: whether it re-proposes to the same counterparty, and what happens when their endpoints or terms have changed since.

3. Automatically pay this subscription toggle
Both Subscribe to Subscription and Renew Subscription carry a purple toggle above the swipe. The app has no toggle: SubscriptionsScreen.kt derives payOnAcceptance from subscription.paymentDueOnAcceptance(now) != null, so it is computed and never user-settable. Building it means persisting an auto-pay preference per subscription and deciding what happens on a failed automatic payment.

4. Swipe knob colour: fixed brand, or derived from the balance being spent?
Open design question, currently shipped as fixed brand orange.

Every other confirm swipe in the app follows the balance it spends — SendConfirmScreen does ONCHAIN -> Brand, LIGHTNING -> Purple, SavingsConfirmScreen is Brand, SpendingConfirmScreen and ExternalConfirmScreen are Purple, Boost is Yellow, and hardware is Blue (see #1259). The subscription success confetti already follows the rail too, via subscriptionConfettiResource.

Subscriptions are the exception: the swipe is hardcoded. The design system supports the distinction — the component is a variant set named Swipe to Pay with Savings and Spending variants — but all three subscription frames instantiate the Savings variant, knob #FF4400. It is unclear whether that is deliberate or just the default variant being dropped in.

The visible consequence today: accepting a lightning-paid subscription shows an orange accept swipe and then immediately opens the send flow with a purple pay swipe.

A rail-derived implementation was written and reverted in #1269 pending this decision. To reinstate, cherry-pick 4f64643ae and bfdda4d9f; they add acceptsLightningPayment and isPaidFromSpending(maxSendLightningSats), requiring both that the payee accepts lightning and that the sender can actually cover the amount from spending, plus unit coverage.

Alternatives considered

Shipping 1–3 as rendering-only stubs was rejected: each control implies a flow that does not exist, so a button that does nothing would be worse than its absence. For 4, leaving the subscription swipe hardcoded is defensible as long as it matches the frames, which is why #1269 ships it that way.

Additional context

• Design pass: fix: match subscriptions screens to handoff design #1269
• Handoff page: Bitkit - Handoff v62, Subscriptions section
• Related swipe-colour bug: [Bug]: HW on-chain send confirm uses the orange on-chain swipe slider instead of blue (Android only; iOS is blue) #1259
• Journeys for the shipped behaviour live in journeys/subscriptions/; they do not cover any of the above, and journeys/README.md records the suite as not yet ported to bitkit-ios
• iOS carries the same four gaps, so whichever way these land should land on both sides