TypeScript: each key of a module-level const object literal is a declaration

[swapnilpaliwal-sd]

Keys of export const TOPICS = { a: '…' } as const (topic, route, event-type and token tables) were declared nowhere: impact TOPICS.a answered "nothing named" and readers of one key could not be told from another's.

• parser: an unannotated module-level const whose value is an object literal (through as const, satisfies, parens, Object.freeze) emits each data key as a field of the variable; nested literals nest.
• field_access.dl: X.a resolves to that key through the variable, an import, a namespace import or an outer key, only when the typed lookup found nothing (satisfies T keeps T's member).
• a read in a method's or parameter's decorator, or in a parameter's default, is credited to that method, not the module.
• impact: a key spelled like a class (TOKENS.Relay) answers as the key; two tables with the same key in one file stay apart.
• controls: annotated/satisfies consts, keys added after the literal, function-valued keys, a function written as a default.

Checked: TS engine suite 99/99; golden cases TS 225/225, JS 277, Python 278, Java 306, C# 207 all pass. Product probes 47 → 52/74, 0 regressed; call edges unchanged (10045), field reads resolved 2196 → 2453.

[swapnilpaliwal-sd]

Two things to fix before this can merge:

1. The TypeScript engine suite fails on 78-cross-process-destinations and 80-object-literal-member-receivers. This PR updates their .fields goldens, but their .fields-oracle goldens changed too, and those are not updated.
2. Declare the data keys of module-level const objects #1826 adds the same behaviour for JavaScript (each key of a module-level const object is a declaration), in the same three files: axiomcode-impact, axiomcode-index and dl/impact.dl. Merge Declare the data keys of module-level const objects #1826 first, then rebase this PR onto it and share one implementation between the two languages, instead of adding a second.

[swapnilpaliwal-sd]

CI fix: 78-cross-process-destinations and 80-object-literal-member-receivers failed with "fields-oracle changed".

• The engine now resolves those const-table key reads. The fields scorer labelled such a key X#a (its owner is the variable, no type), while the compiler side labels it by its module, so each correct read scored as one wrong plus one missing.
• The scorer now names an object-literal key with no type owner by its module; both goldens reblessed as a real improvement.
• Checked: 78 fields 0/1 -> 1/1 correct, 80 fields 0/9 -> 3/9 correct, 0 wrong in both; TypeScript suite with --oracle 99/99 after rebase onto apps/integration-0.1.9.

[swapnilpaliwal-sd]

#1826 has merged, so this now conflicts in dl/impact.dl: both PRs add a rule that a same-named key declared by another object on the line is a declaration, not a use. Resolve it as one rule: keep #1826's key_decl_at, and add this PR's restriction to targets owned by a module (other_field_line), so a type's field keeps its keys ({ eventId: … } satisfies T). Check it against #1826's case, this PR's cases, and typescript/object-key-beside-a-bound-access.

[swapnilpaliwal-sd]

Rebased on apps/integration-0.1.9, which had meanwhile gained an index-side declaration of const-literal keys.

• For TypeScript the parser is now the only owner of those keys: an annotated const's keys are no longer declared beside the type's member.
• A const annotated with a memberless map type (Record<K, V>, index signatures) declares its literal's keys too.
• Fixture 86's const-table reads now resolve (fields recall 0.50 -> 0.92 against the compiler).

Checked: TS cases 243/243, JS cases 285/285, TS suite 100/100, parser TS tests 49/49. On the product, probes were 52/74 before and after. Field reads at known_edge went from 2160 to 2417, and index time was 29.3s before and 29.2s after.