fix(core): validate locate coordinate types strictly

[linhongyu510]

Summary

• reject null, boolean, empty, and whitespace-only coordinate values
• preserve support for valid decimal coordinate strings
• require point results to contain exactly two coordinates
• add regression coverage for JavaScript coercion edge cases

Problem

The shared locate-result parser used Number(value) for arbitrary values. This allowed malformed model output such as null, false, or an empty string to become finite coordinates and proceed into the grounding pipeline:

Number(null)  // 0
Number(false) // 0
Number(true)  // 1
Number('')    // 0

Point responses with extra coordinates were also silently truncated because the parser only required at least two values.

Changes

Coordinate values now accept only finite numbers or complete decimal number strings. General JavaScript coercion is no longer used, and point responses must contain exactly two values.

This keeps compatibility with numeric strings while ensuring malformed model output reaches the existing semantic-retry path instead of becoming a real device coordinate.

Validation

• locate-result codec tests: 33 passed
• model-adapter and codec suite: 28 files, 314 tests passed
• Core build type-check: passed
• Biome: 1604 files passed

[linhongyu510]

CI triage: all four PRs have the same 14-job failure fingerprint. On #3066, 12/14 failed jobs explicitly report that MIDSCENE_MODEL_NAME is unavailable; the remaining e2e-web/e2e-report checks are generic failures from the same model-backed workflow. The workflows inject repository secrets/variables on pull_request, and equivalent same-repository PR runs succeed, while newer external-fork runs are action_required. This is an external-fork trust/configuration gate, not evidence that the changed code failed. This branch is currently mergeable and only one commit behind main, so I am intentionally not force-pushing just to rerun the same restricted matrix. A maintainer can validate via a trusted branch or workflow_dispatch after reviewing the diff; switching to pull_request_target would not be an appropriate workaround.