Accept the system In progress prefix in ProgressView unit-test assertions #527

Description

Main CI run 40502617023 at a96e436 failed in the iOS tests job's "Run iOS unit tests" step. Its "Verify function risk and release phase failure fixtures" step, the cause of run 40313385205, now passes, because #524 listed the #520 journeys in scripts/pro-release-phases.json.

Two unit tests failed, and 1,182 passed:

• FreeTierPresentationTests.testDashboardShowsLoadingUntilInitialRefreshCompletes: expected "Loading accounts…", got "In progress, Loading accounts…".
• ProviderUsageCardHiddenSeverityTests.testResetInventoryShowsProgressThenFeedbackWhileUsingConfirmedReset: waited 5 seconds for "Using reset…", but the labels only contained "In progress, Using reset…".

The same pair failed together with identical labels in run 39799242125 on October 22, on a different image (20261013.0424.1). They passed on the same image and runtime in runs 40146062194, 40215906682 and 40345384586. Neither the views nor the tests changed between those runs. On some hosted simulator sessions, SwiftUI reports a labelled ProgressView as "In progress, <label>"; on others it reports "<label>". Both are system output, and the app's text is correct in both cases.

On air, with Xcode 26.6, an iOS 26.2 iPhone Air and 5 iterations, the reset test passed 5 of 5. The loading test failed once, separately: it reads the element once with settles: false, and the element was nil.

Acceptance Criteria

• Both tests accept exactly "<label>" or "In progress, <label>" for these ProgressViews, and still reject any other label.
• No product UI or accessibility text changes.
• Tests that automatic PR CI runs are unchanged, so automatic CI cost is unchanged.
• A manual full CI run on main passes the iOS tests job.

Validation

• Pinned toolchain (Xcode 26.6, iOS 26.2): run the two tests repeatedly, then run the full CodexBarIOSTests suite.
• Dispatch ci.yml on main after merge and confirm it passes.