Fix string-to-integer coercion in query matching

[bparth24]

Tests

Added to tests/unit/query.match.spec.js (with a supporting credential in
tests/unit/mockCredentials.js):

• "3.14" must not match an integer query for 3
• "21abc" must not match an integer query for 21
• "21" still matches 21 (valid coercion preserved)
• decimal-as-number does not match a decimal string (locks in the
  no-decimal-coercion boundary)

Addresses #74

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.02%. Comparing base (834c278) to head (0e22507).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #79      +/-   ##
==========================================
- Coverage   54.05%   54.02%   -0.04%     
==========================================
  Files          21       21              
  Lines        4266     4263       -3     
==========================================
- Hits         2306     2303       -3     
  Misses       1960     1960              

Files with missing lines	Coverage Δ
lib/query/dcql.js	91.05% <100.00%> (ø)
lib/query/match.js	95.00% <100.00%> (ø)
lib/query/util.js	97.05% <100.00%> (-0.09%)	⬇️

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 834c278...0e22507. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[davidlehn]

• Does this need more edge case checks?
• Might consider at least having a zero and negative int check. Probably Number.MIN/MAX_SAFE_INTEGER too.
• Does this need the reverse checks of data with a plain int and query with an int string? I think the code would handle that?
• Parsed JSON itself with native ints will (probably?) be limited to Number.MIN/MAX_SAFE_INTEGER. But if both sides had strings with non safe int values, I think this starts to lose precision and would cause matching failures. In any case, havoc will probably happen. Is that important to handle here?

Example:

> Number.MAX_SAFE_INTEGER
9007199254740991
> a = parseInt('9007199254740992')
9007199254740992
> b = parseInt('9007199254740993')
9007199254740992
> a.toString()
'9007199254740992'
> b.toString()
'9007199254740992'
> a.toString() === b.toString()
true

• One solution might be to use BigInt(x), but that's introducing radix prefix issues and returning BigInts vs ints for comparison and no doubt has odd issues.
• Another solution is to specifically not handle these issues and after the parseInt, check if Number.isSafeInteger(i) is false, then return x. Would need some tests to make sure that works and simply refuses to match those non-safe string values for now.

[dlongley]

@davidlehn using BigInt would cause trouble, but your suggestion of using Number.isSafeInteger(i) seems like it could work.

[dlongley]

I'm going to merge this now. We can add the extra checks, whatever we decide those are, in a subsequent PR.