[Local catalog] Ignore time based sync eligibility inside POS

[joshheald]

Description

This PR improves some theoretical issues with sync eligibility checking. I've not been able to really recreate these, but you probably could if you left an iPad in kiosk mode for a month or more.

We determine time-based sync eligibility based on:

• Has the POS ever synced? If not, assume eligible.
• Has it been 30 days since the POS first synced? If less, assume eligible.
• Has the user opened POS in the last 30 days? Eligible if true, ineligible if false.

These criteria are designed for syncs which are performed when POS isn't in use… if someone's actively using POS, they don't make sense.

To fix it, we can just ignore the time-based sync eligibility criteria when POS is actually in use. I achieved this by checking for a max catalog age of zero in a refresh. When that's true, we’re forcing a sync – e.g. because of a pull to refresh, or a full sync from settings, or after a purchase.

When we do this, we should ignore temporal reasons for not syncing. Otherwise, it’s possible to get into a position where syncs don’t work any more even though they should.

Test Steps

• Replace .day with .second in all instances in POSCatalogSyncCoordinator
• Launch the app and open POS
• Pull to refresh
• Observe that the sync completes and the following is logged:

📋 POSCatalogSyncCoordinator: Site 216335538 eligible (ignored temporal criteria check)

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

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

	App Name	WooCommerce iOS Prototype
	Build Number	pr16423-f062cb2
	Version	23.8
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	f062cb2
	Installation URL	47kb1ahulr9mo

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