[WOOMOB-3799] Propagate and persist custom authentication endpoints (2/3)

[hichamboushaba]

Description

Fixes WOOMOB-3799

Part 2 of 3, stacked on #16396 and followed by #16398.

This is one direct-site-credentials fix split into three PRs for review; the parts are not intended to ship independently. Review this diff against PR1's head. Merge order is 1 → 2 → 3, once the whole stack is approved.

PR1 can verify custom cookie-authentication endpoints, but the app still needs to carry those values through authentication, preserve meaningful failures, and store proven endpoints safely. This PR adds that plumbing without adding user-facing recovery UI.

The changes fall into three areas:

1. Authentication and nonce refresh

   • Structured endpoints are used for initial nonce acquisition and later cookie-authenticated REST requests.
   • A protected request only runs with an available nonce. If initial acquisition fails, the REST callback is not invoked.
   • If a cached nonce is rejected and refreshing it fails, the original REST request runs only once and the refresh failure is returned.

2. Failure provenance

   • The loginEntryVerified signal from PR1 reaches the app, so a failure after a proven sign-in page is not misreported as an unknown custom login URL.
   • Nonce-stage failures keep their useful type and message while dropping their HTTP response metadata. This prevents a login/admin 404 from being mistaken for a stale REST root, or a nonce status from being interpreted as an Application Password endpoint result.

3. Persistence and refresh

   • Saving custom endpoints succeeds only after the site update affects a row and the stored SiteModel can be reloaded with the normalized values.
   • Dispatch, zero-row, reload, or value-mismatch failures restore the caller's original in-memory fields and surface the failure to the caller.
   • Later site refreshes preserve verified custom endpoints while still allowing stale admin metadata previously inferred from the REST Application Password authorization URL to be replaced.

Review map:

• CookieNonceAuthenticator.kt: endpoint-aware initial/refresh nonce flow and failure propagation.
• SiteWPAPIRestClient.kt: verified endpoint preservation during site refresh.
• WPApiSiteRepository.kt: endpoint forwarding plus persist-and-reload confirmation.
• Three focused test files cover nonce failures, refresh behavior, stale metadata, and persistence failures.

This PR adds no strings or standalone UI. QR login, XML-RPC, and Application Password architecture remain unchanged.

Test Steps

Because custom endpoints cannot be entered until PR3, perform the custom-endpoint steps using the top-of-stack build.

1. Sign in to a self-hosted store using standard WordPress endpoints and confirm authenticated data such as Orders and Products loads.
2. Sign out, repeat with an incorrect password, and confirm no authenticated store content is shown.
3. Using the top-of-stack build and a store with custom login/admin endpoints, complete native login, force-stop the app, relaunch it, and confirm the store opens without asking for either endpoint again.
4. Refresh an authenticated screen after relaunch and confirm data loads through the persisted endpoint configuration without a browser or repeated login loop.

Images/gif

N/A — this PR contains authentication and persistence plumbing only.

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

The stack's single user-facing release note is owned by PR3.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Build Number	778
	Version	25.4-rc-1
	Application ID	com.woocommerce.android.prealpha
	Commit	cdd77c4
	Installation URL	5sj6kaat1p56o

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[claude]

AI Code Review - Found 1 potential issue

This is a careful, well-tested refactor of the cookie-nonce authentication flow. Highlights:

• The public makeAuthenticatedWPAPIRequest signature change is safe: all callers (CookieNonceWPAPINetwork, WPApiApplicationPasswordsRestClient, JetpackWPAPIRestClient) use nonce.value and already return WPAPIResponse<T>, and they now benefit from a non-null nonce (Available).
• Backwards compatibility is preserved via the retained authenticate(siteUrl, ...) overload and the default endpoints param on WPApiSiteRepository.login(...).
• Short-circuiting on nonce-acquisition failure (nonce.toErrorResponse()) correctly produces an error with no volleyError, so it is not misread as a 404 by the outer retry logic.
• Endpoint-preservation logic in SiteWPAPIRestClient (preserve verified/manual admin+login URLs, discard stale inferred ones) is sound and well covered by the new tests.

One minor edge case is flagged inline.

PR housekeeping

• Applied repo AGENTS.md/CLAUDE.md guidance (FluxC data-layer conventions, Kotlin style, no wildcard imports).
• Test coverage is strong across the changed behavior; no gaps of concern.

---

_{Automatic review · claude-opus-4-8 · Workflow run}

_{How to reply to a finding}

Reply on this review (or inline at the line the finding refers to) with one of:

• @claude addressed - I made the change. Bot verifies against the next diff before marking resolved.
• @claude rejected: <reason> - Will not fix; reason gets quoted on the next review.
• @claude not-applicable - Finding does not apply (wrong file, already covered elsewhere, etc.).

The bot honours these on the next review pass.

[AdamGrzybkowski]

Great work!