experimentalDecorators: a class name used as an object literal key is renamed to the self-reference alias

@RyanCavanaugh đang làm issue này rồi.

Từ ngày 15/7/2026.

• #4650 của @copilot-swe-agent — đã đóng, không merge

**Version:** 7.0.2 (the `tsc` from the `typescript` npm package). Emits correctly on 6.x.

With `experimentalDecorators` on, when a decorated class uses its own name as an object literal property key inside its body, the emitter rewrites the key to the decorator self-reference alias (`SessionAuth` becomes `SessionAuth_1`).

## Repro

`experimentalDecorators: true`:

```ts
const dec = (t: any) => t;

@dec
class SessionAuth {
static requirement() {
return { SessionAuth: [] };
}
}
```

Expected emit (what 6.x produces):

```js
static requirement() {
return { SessionAuth: [] };
}
```

Actual emit on 7.0.2:

```js
var SessionAuth_1;
let SessionAuth = SessionAuth_1 = class SessionAuth {
static requirement() {
return { SessionAuth_1: [] };
}
};
SessionAuth = SessionAuth_1 = __decorate([dec], SessionAuth);
```

The `SessionAuth` in the object literal is a property name, not a reference to the class, so it should be left alone. The wrong key only shows up at runtime. In our case it renamed an OpenAPI security scheme key and broke request validation after we upgraded.

The same substitution happens for other name positions that match the class name (a shorthand method name, a class field name). Property access on other objects and string-literal keys are not affected.

## Likely a missed instance of a known problem

This looks like the same root cause as microsoft/typescript-go#3146 (enum member access with the same name as a decorated class), which was closed via microsoft/typescript-go#3147. That fix covered the enum-access position; the object-literal-key position seems to have been missed. Might be worth checking whether the fix can be widened to cover all name positions rather than the enum case on its own.