fix(ios): honor maximumAge in getCurrentPosition instead of returning stale cached positions

[binikingi]

Description

On iOS, getCurrentPosition ignores the maximumAge option entirely and can resolve with a stale cached position. This PR makes the iOS implementation honor maximumAge as documented (and as Android and Web already do): a position older than maximumAge no longer satisfies getCurrentPosition — the call stays pending while a fresh position is acquired (falling back to continuous updates when needed), still bounded by the existing timeout handling.

Details of the change:

• maximumAge is now read from getCurrentPosition calls (stored alongside the existing shared timeout, same last-caller-wins semantics).
• Positions delivered by the location service are checked against maximumAge before resolving pending single-location calls. Because CLLocation timestamps lag delivery by the acquisition time, positions younger than a 5s freshness threshold are always accepted, so the default maximumAge: 0 keeps resolving with freshly acquired fixes.
• When a stale position is rejected and no watch is running, the plugin starts monitoring to force a fresh fix (re-arming the timeout timer, which the stale delivery had cancelled) and stops monitoring again once the request is satisfied. If a watch is already running, the next live update resolves the call.
• Watch callbacks are unaffected: they continue to receive every update, including the ones rejected for single requests.

Context

There are two ways iOS currently hands back stale coordinates:

1. CLLocationManager.requestLocation() frequently delivers the system's last known location — taken minutes earlier, before the device moved — and nothing checks its timestamp.
2. Since IONGeolocationLib 2.x, requestSingleLocation returns the in-memory currentLocation verbatim whenever monitoring is active, with no freshness check at all.

Either way the position carries its original (good) accuracy value, so callers have no signal that the coordinates are outdated. In our production home-care app, caregivers clocking in at a patient's home get positions 1.5–3 miles away — reported as accuracy: ~16m — because the fix predates their drive over.

This is very likely the same root cause behind #68 and #69 ("wrong coordinates on iOS, fine on Android/Web"), both closed for lack of response. The answer to the question asked there ("are you receiving outdated location?") is yes: the coordinates are outdated, and only position.timestamp reveals it.

Type of changes

• Fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Refactor (cosmetic changes)
• Breaking change (change that would cause existing functionality to not work as expected)

Platforms affected

• Android
• iOS
• JavaScript

Tests

• npm run verify:ios (xcodebuild) builds successfully.
• SwiftLint: no new violations (the two nesting warnings on GeolocationConstants.swift pre-date this change).
• The existing iOS test target is a template stub that references a class that no longer exists, so no unit tests were added here; happy to add coverage (e.g. via an injectable IONGLOCService fake) if you can point me at the preferred approach.
• Manual verification in a production app: with this patch, a getCurrentPosition call issued right after arriving at a new location waits for a live fix instead of resolving with the pre-drive cached position.

Screenshots (if appropriate)

Checklist

• Code follows code style of this project
• CHANGELOG.md file is correctly updated (generated by semantic-release from the conventional commit)
• Changes require an update to the documentation
  • Documentation has been updated accordingly