Add a style-configurable Demo screen for the saved payment method component

[rainaarya]

Summary of changes

Adds a Demo screen for PayPalSavedPaymentMethodView.

Depends on #1887 (3/6) and #1888 (4/6). It builds once those merge.

• PayPal Saved Payment Method integration in Demo settings, with an amount field and a PayPal App Switch toggle.
• Edit Style sheet that sets every PayPalSavedPaymentMethodViewStyle value. Each value can be left unset so the SDK default applies.
• With the custom environment and Client Token selected, the Demo uses the token pasted into Custom Authorization. The component needs a client token that carries paymentMethodIdJwt.

Testing

1. Settings: Environment Custom, Authorization Type Client Token, paste a client token with paymentMethodIdJwt into Custom Authorization, Integration PayPal Saved Payment Method.
2. The saved funding instrument and Pay Later message load. Changing the amount refetches the message.
3. Change values in Edit Style; Reset restores the defaults.
4. Tap the funding instrument, complete the edit, and confirm a nonce is returned.

AI Usage

Which AI Agent Was Used?

• Copilot
• Claude
• Other (Type Name Here)

How was AI used?
Used Copilot to write the Demo screen and style editor, and to port them onto the split component PRs.

Estimated AI Code Contribution

• less than 30%
• 30 - 60%
• 60 - 100%

Checklist

• Added a changelog entry
• Tested and confirmed payment flows affected by this change are functioning as expected

Authors

List GitHub usernames for everyone who contributed to this pull request.

• @rainaarya

---

Inner Source Process

Internal to PayPal contributors should fill out this section. All others can delete.

PR should follow these steps before codeowners review will begin:

1. Comment /inner source on this PR — this will automatically add the inner source and tech lead review required labels. Open the PR in a draft state.
2. PR should be reviewed by and approved by your team's technical lead, we do not allow LGTM reviews, there should be comments and feedback provided on all PR reviews
3. Once the above steps are completed, comment /ready on this PR — this will automatically remove the tech lead review required label. Move the PR to ready to review.
4. PR comments must be addressed within 24 hours, if you are unable to address within this timeframe, move the PR back to a draft state so our team knows not to review

Inner Source Checklist

• Added all labels to the PR
• Provide steps to test the flows changed, if applicable in the summary
• Demo video of the functionality, if applicable
• All upstream dependencies are merged in and this PR can be released at any time; PRs should not be opened until this is true
• Unit tests and builds have been run locally and pass/compile as expected

[Juan219]

Could we verify that this does not duplicate appearance callbacks? UIKit automatically forwards
appearance callbacks to child view controllers by default; manual beginAppearanceTransition /
endAppearanceTransition forwarding is needed when the container overrides
shouldAutomaticallyForwardAppearanceMethods to return false.

I do not see that override in ContainmentViewController, but please confirm whether any subclass opts
out of automatic forwarding. If not, a small regression test asserting a single initial onAppear /
viewDidAppear would help ensure we do not trigger duplicate initial loads.

Apple documentation:

https://developer.apple.com/documentation/uikit/uiviewcontroller/shouldautomaticallyforwardappearancemethods

[rainaarya]

Yeah thanks for pointing this, I measured it and the manual calls did indeed double viewWillAppear/viewDidAppear. I removed them all and each now fires once while the component still loads.