Investigate and design: give repeated class evaluations independent identity and computed-key state

[nickna]

Verify and resolve this specific recorded finding from #1599. Parent: #1866. Plan ID: B07.

Evidence status: recorded in earlier issue/PR evidence, not freshly reproduced by the decomposition work. Current failure, root cause and applicability of later fixes remain to be established.

Source and frozen observation

Recorded after #1849–#1851; distinct syntax-node ownership in #1859 does not prove repeated evaluation is fixed

Original progress note.

Specific target

Repeated execution of one class expression produces distinct constructors and isolated captured keys; preserve generic-instantiation behavior

Acceptance

• Recover the original source/diagnostic/output and reference expectation from the linked phase or retained artifacts. Preserve original deadlines and failures.
• Check for an existing exact issue and later fixing commits before creating overlapping implementation work.
• Test the original case on a recorded current baseline and distinguish interpreted, in-process compiled, CLI/standalone and hosted coverage as applicable.
• Record whether each named observation still fails, is already repaired, is an exact duplicate, or lacks recoverable evidence.
• Produce a bounded design decision and separate finite implementation tasks if required.
• Link the disposition and applicable evidence; successful IL verification alone is not runtime correctness.

Done when: A recovered current reproduction (or demonstrated prior repair), a bounded representation/design decision, and explicit finite implementation issues if a larger change is needed. This investigation may close after the design/transfer; it must not claim the behavior was repaired.

Excluded: full compatibility of the surrounding API/family, unrelated discoveries, and reopening completed ownership migrations.

Scope boundary

This is a bounded successor to #1599, based on commit 83a4109. Work only on the named symbols or observations. Record unrelated discoveries separately; do not expand this issue or automatically start another task after completion. A passing IL verifier does not establish correct execution. Preserve original failures and expectations when reporting a pre-existing defect.