[POS] Better error handling for eligibility

[toupper]

Closes WOOMOB-1016

Only one review required, but I add you both as reviewers in case you are interested in the solution.

Description

With this PR we improve the logic for handling errors when opening POS, including when there is no connection. We implement this logic:

POS tab eligibility

• Positive → Show POS tab.
• Negative → Hide POS tab.
• Unknown (e.g., backend error) → Show tab using last cached value.
  When entering POS tab and eligibility check errors again:
• Cached Positive → Allow access to POS.
• No Cache → Deny access and show error message.

For that we:

• Update AppPrefs to cache also whether POS was launchable. We also update the tab logic to only make it possible to cache positive cases.
• Update WooPOSIsRemotelyEnabled, WooPosCanBeLaunchedInTab and WooPosTabShouldBeVisible to return a result instead of a boolean
• Refactor WooPosCanBeLaunchedInTab with the new logic, including setting the value in cache.

Steps to reproduce

With all conditions met:

• Start the app with internet connection
• Verify the POS tab is visible
• Tap on it and access POS
• Kill the app
• Turn on airplane mode
• Start the app
• Notice the POS tab is visible (before it was not)
• Tap on the tab and access POS

With the POS feature switch disabled in wp-admin:

• Start the app with internet connection
• Verify the POS tab is visible
• Go to the POS tab
• Verify that you get an error about the feature switch disabled
• Kill the app
• Turn on airplane mode
• Start the app
• Notice the POS tab is visible
• Go to the tab
• You cannot enter POS and a genetic message is shown

With a store in a country other than US or UK:

• Start the app with internet connection
• Verify the POS tab is not visible
• Kill the app
• Turn on airplane mode
• Start the app
• Notice the POS tab is not visible

Testing information

The tests that have been performed

See above

Images/gif

On this video we can see how the tab is shown in airplane mode because it was shown before, but given that we never cached whether the POS was launched, we prevent accessing it:

Screen_Recording_20250813_143918_Woo.Pre-Alpha.mp4

Here we show how if previously the user accessed POS, it can access it even if there's no connection:

Screen_Recording_20250813_144433_Woo.Pre-Alpha.mp4

• 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.

[wpmobilebot]

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

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	1ac9b92
	Direct Download	woocommerce-wear-prototype-build-pr14463-1ac9b92.apk

[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
	Commit	1ac9b92
	Direct Download	woocommerce-prototype-build-pr14463-1ac9b92.apk

[malinajirka]

Thanks for working on this @toupper! I've reviewed the code and left some questions/suggestions. I haven't tested the behavior yet. Let me know what you think and I'll test it when we resolve these discussions.

[toupper]

Thanks for your comments @malinajirka! I addressed them and refactored the code a bit to make it cleaner and easier to read. Please let me know what you think

[malinajirka]

Thanks for all the changes! The tests are failing, other than that LGTM . I've left question but feel free to ignore it.

[malinajirka]

💡 I'm wondering if this should be set to false when forceRefresh is true, wdyt?

[malinajirka]

❓ Is this test correct, why do we want to return tabVisible when remote FF is disabled?