W-23159884: Add stable test tags to login screen and server/account picker

[brandonpage]

W-23159884: Add stable test tags to login screen and server/account picker

What & why

Login-screen and server/account-picker UI tests previously anchored on localized contentDescription/text strings (the sf__* string resources). Those anchors break under non-English locales and right-to-left layouts, which is the accessibility-anchor concern tracked by the parent story.

This change introduces stable, locale-invariant Modifier.testTag anchors and routes all test/page-object code through them.

Changes

• New public API — LoginViewTestTags object (com.salesforce.androidsdk.ui.components): the single source of truth for the locale-invariant test-tag resource-ids. Intentionally public so SDK instrumented tests, sample-app page objects (AuthFlowTester), and external UTAM page objects all reference the same constants. Replaces the former internal const val TAG_* block in LoginView.kt.
• Production UI — applied/migrated tags in LoginView.kt (more-options button, back button, the 6 overflow menu items, loading indicator, login button), PickerBottomSheet.kt (server/account picker containers, back/close buttons, add-connection button, custom label/URL fields, apply button), and LoginServerListItem.kt (server delete + confirm-delete targets).
• Tests — migrated PickerBottomSheetTest.kt (SalesforceSDKTest) and LoginPageObject.kt (AuthFlowTester) to anchor on the tags. Row-identity matchers that assert rendered content (hasText(name) and hasText(url)) are intentionally retained; Espresso WebView fields and the native AlertDialog path are untouched (not Compose / not taggable).

Reviewer notes

• Public API addition (LoginViewTestTags) — flagged per SDK escalation rules. No metalava/API-validator dump exists in the repo, so nothing to regenerate.
• No sf__strings.xml change — these are resource-id test anchors, not user-facing localized strings.
• The composition roots that host these nodes already opt in with testTagsAsResourceId = true, so the tags surface to UIAutomator2/UTAM as Android resource-ids.

Testing

• Compile-verified: production, SalesforceSDKTest androidTest, and AuthFlowTester androidTest source sets all build clean.
• Instrumented suites run in CI on Firebase Test Lab.

[brandonpage]

This might appear to be an over investment given our future Login UX plans, but I actually see it being a useful bridge. If/when we introduce a new SDK provided default UI in 15.0 we can ensure these tags are used. And since they are public consuming apps can use them in their UI implementation if they chose to create their own. This make UI tests easier to migrate and hopefully ease the transition.

[wmathurin]

Both SERVER_DELETE_BUTTON and SERVER_CONFIRM_DELETE_BUTTON are shared by every row in the list — all delete buttons get the same tag by design. That's expected Compose behaviour, but it will surprise the first person writing a test that targets a specific server row. Worth adding a one-liner KDoc note here (and on SERVER_DELETE_BUTTON above) pointing to the row-identity pattern:

// To target a specific row, combine with a content matcher:
// onNode(hasTestTag(SERVER_DELETE_BUTTON) and hasAncestor(hasText("MyOrg")))

[brandonpage]

Tests will fail on the latest run because the test org goes down for maintenance every day ~4 PST. All test passed on the first commit and my second commit only added comments.