Native/WASM definitions array order diverges for object-literal method extraction

[carlos-alm]

Summary

For export const obj = { ..., method() {} } (an object literal whose value contains a shorthand method), both the WASM and native JS/TS extractors emit the same set of definitions entries, but in a different relative order — surfaced while adding a cross-engine parity test for issue #1728.

Given:

export const add = (a, b) => a + b;
export const command = {
  name: 'info',
  execute(args, opts, ctx) {},
};
const INTERNAL = 'not exported';

Both engines emit all of:

• command (constant)
• command.execute (function, qualified — no children; from extractObjectLiteralFunctions/extract_object_literal_functions, used for callback/pts resolution)
• execute (method, unqualified — with args/opts/ctx parameter children; from the generic method_definition walk)
• INTERNAL (constant)

WASM order: command, command.execute (inline, adjacent to command), ..., INTERNAL, execute (appended at the end by a later collector pass).

Native order: command, execute (inline, adjacent to command), ..., INTERNAL, command.execute (appended at the end by a later pass).

So the qualified and unqualified entries swap which one is emitted inline vs. deferred-to-end between the two engines. Content is identical; only array position differs.

Impact

Currently cosmetic — node insertion is order-independent (batch INSERT OR IGNORE), so the resulting graph/DB is unaffected. But it means any test or consumer that does a strict ordered-array comparison of raw definitions output (rather than sorting/set-comparing first) will see native and WASM diverge. tests/engines/parity.test.ts's normalize() does not sort definitions (unlike tests/engines/query-walk-parity.test.ts, which does), so it's the one place this is currently visible — a test case exercising this exact shape had to be trimmed to avoid tripping over it (see PR fixing #1728).

Suggested fix

Align the two engines on whether the qualified (obj.method) or unqualified (method + children) extraction runs inline (adjacent to the object literal's own definition) vs. as a deferred/collector pass — whichever ordering is more natural for the architecture — so definitions order agrees between engines. Alternatively (lower priority), make tests/engines/parity.test.ts's normalize() sort definitions the same way query-walk-parity.test.ts does, since order is not semantically meaningful for this array.

Found while

Investigating issue #1728 (exported-symbol detection) — adding a cross-engine parity test case covering export const initializer shapes surfaced this pre-existing, unrelated ordering difference. Not fixed here to keep that PR scoped to the export-list bug.