$populate: a number-typed FHIRPath result never matches a valueInteger answerOption

[leoniedickson]

Describe the bug

findInAnswerOptions (packages/sdc-populate/src/SDCPopulateQuestionnaireOperation/utils/answerOption.ts) matches valueInteger options by string comparison only:

if (typeof option.valueInteger === 'number') {
  if (value === option.valueInteger.toString()) {
    return { valueInteger: option.valueInteger };
  }
}

value is compared against option.valueInteger.toString(), but value itself is never converted to a string first. This works when value is already a string (e.g. from user-entered text), but an initialExpression FHIRPath result that evaluates to a genuine JS number (e.g. Observation.valueInteger) fails the comparison outright — 5 === "5" is false under strict equality. The answer then falls through to the numeric branches in parseValueToAnswer instead of returning the matching, normalised option.

To Reproduce

import { findInAnswerOptions } from './utils/answerOption';

const options = [{ valueInteger: 5 }];

findInAnswerOptions(options, 5);   // number
findInAnswerOptions(options, '5'); // string

Expected behavior

Both calls should return { valueInteger: 5 } — the answerOption match shouldn't depend on whether the FHIRPath result happened to be a number or a string.

Actual behavior

findInAnswerOptions(options, 5)   // undefined
findInAnswerOptions(options, '5') // { valueInteger: 5 }

Additional context

• Found while reviewing fix (sdc-populate) $populate silently drops open-choice answers that are not in answerOption #2096 (which fixes $populate silently drops open-choice answers that are not in answerOption #2095) — pre-existing and not touched by that PR, except for the zero-valued variant: {valueInteger: 0} was previously skipped by a falsy guard on that same line, and fix (sdc-populate) $populate silently drops open-choice answers that are not in answerOption #2096 fixed that specific bug because the line was already being rewritten. The underlying string-only comparison for any other number is untouched.
• A fix likely just needs value.toString() === option.valueInteger.toString() (or an equivalent numeric-aware comparison) instead of comparing value directly against a string.
• Originally noted by @not-in-stock in a comment on $populate silently drops open-choice answers that are not in answerOption #2095.