processAttr: NaN default value silently breaks identity check

[cursor]

Problem

processAttr(undefined, defaultValue) returns defaultValue via identity (return defaultValue), but if a feature author passes NaN as the default, downstream comparisons like result === expected will always be false because NaN !== NaN in JavaScript.

This was discovered via a property test that generated NaN as a default value. While feature authors don't currently pass NaN, the function has no guard against it.

Options

1. Document that NaN is not a supported default — cheapest, matches current reality
2. Normalize NaN to undefined or null — defensive, prevents subtle bugs if a config accidentally produces NaN (e.g. parseInt('abc'))
3. No change needed — if the type system (ConfigSetting) already prevents this

Context

Found in PR #2261. The property test was narrowed to realistic defaults as a workaround.

// src/utils.js — processAttr
if (configSetting === undefined) {
    return defaultValue; // if defaultValue is NaN, callers can't compare the result
}

[jonathanKingston]

@cursoragent can you fix please?

[cursor]

Fixed. Here's what I did:

• Added a NaN guard at the top of processAttr in injected/src/utils.js that normalizes NaN defaultValues to undefined before any code path can return them. This is option 2 from the PR — defensive normalization that prevents subtle bugs if a config accidentally produces NaN (e.g. parseInt('abc')).

• Added tests in both unit-test/utils.js (3 assertions covering undefined, non-object, and object-without-type code paths) and unit-test/utils-properties.spec.js (property test confirming NaN is normalized). All 37 processAttr specs pass. Lint is clean on the changed files. The 13 pre-existing test failures are unrelated (missing build artifacts).