Improve catalog filter behavior when min price exceeds max price

[noevidence1017]

closes #68

Summary

On the catalog screen, typing a minimum price above the maximum kept the price filter active. Since no resource can satisfy an inverted range, the list emptied and the user saw only the generic "No matches / Try adjusting or clearing your filters" state, with nothing pointing at the price fields as the cause.

The invalid range is now detected and given both parts of what the issue asks for: clear inline feedback, and predictable disabled-filter behaviour.

Behaviour

• Min above max: both price inputs get a danger-coloured border, an inline message appears under them - "Minimum price is higher than maximum price. The price filter is off until you fix the range." - and the price filter is not applied. Search, verification and type filters keep working, so the list shows their result rather than going blank.
• Min equal to max: valid, applied as an exact-price match (bounds are inclusive, unchanged).
• One side only, blank fields, or non-numeric text: unchanged from before.
• Any valid range: unchanged from before, including dropping resources whose price is not numeric while a bound is applied.
• "Clear filters" stays enabled while the range is invalid, so the existing one-tap recovery still works.

Changes

src/utils/priceRange.ts (new)

• parsePriceRange(minPrice, maxPrice) returns the parsed bounds plus isInvalid (both bounds set and min > max) and isActive (has a bound and is valid).
• filterByPriceRange(items, range) applies an active range and returns the list untouched otherwise.
• INVALID_PRICE_RANGE_MESSAGE is exported so the message has a single source.

src/screens/CatalogScreen.tsx

• The inline min/max parsing in the filteredResources memo is replaced by these helpers; the filtering logic itself is carried over unchanged.
• Invalid-state styling on both price inputs, plus an inline error Text with accessibilityRole="alert" and accessibilityLiveRegion="polite" so screen readers announce it; each input also carries the message as its accessibilityHint while invalid.
• Both new styles are theme-driven (colors.danger), so they work in light and dark mode.

src/utils/priceRange.test.ts (new)

• Covers blank and non-numeric fields, single-sided ranges, min equal to max, the inverted range being flagged invalid and inactive, inclusive bounds, and non-numeric prices.

Backend assumptions

None. Price filtering is entirely client-side on the already-fetched catalog, as before - buildQuery does not send price parameters, and no request is made or changed by this PR.

Verification

• npm run typecheck passes.
• Manual verification (catalog with resources priced 1.00 / 5.00 / 10.00): entering min 10 and max 5 shows the two highlighted inputs and the inline message while the list keeps showing all three resources and the "Showing 3 of 3" counter; clearing the max, or lowering the min to 5, removes the message and applies the range again; "Clear filters" resets both fields. No screenshots attached - this was exercised against the extracted filter logic and by walking the render path, since I have no simulator plus a running MindVault server in this environment.
• Unit tests: the repo's npm test currently fails for every suite on main, before this change (TypeError: this._moduleMocker.clearMocksOnScope is not a function - the jest-runtime@30.4.1 override in package.json is paired with jest-expo@52, which brings a jest 29 environment). That pre-existing toolchain mismatch is left alone to keep this PR scoped. The new suite was run against the same source with a config that only swaps in a node test environment: 9 tests, all passing. It will run under npm test unchanged once the jest versions are reconciled.

[drips-wave]

@noevidence1017 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits