Fix invalid declaration emit for constants whose value is Infinity or NaN - #64761

Fixes #64760

Problem

A numeric literal that overflows, such as 1e400, has the number literal type Infinity. Declaration emit writes constants of that type with their literal value, which produces declaration files that don't type-check:

// m.ts
export const a = 1e400;
export const b = -1e400;
export class C {
    static readonly e = 1e400;
}
export default 1.7976931348623159e308;

// m.d.ts, from tsc --declaration on main (b5c34ba)
export declare const a = Infinity;
export declare const b = -Infinity;
export declare class C {
    static readonly e = Infinity;
}
declare const _default = Infinity;
export default _default;

Each initializer is an error when the .d.ts is checked: TS1254: A 'const' initializer in an ambient context must be a string or numeric literal or literal enum reference. Infinity is an identifier, not a literal.

This isn't a TS 7 regression. TypeScript 6.0.3 (Playground) emits the same initializers, and declare const _default: Infinity; for the default export.

Fix

In tsc/internal/checker/emitresolver.go:

• IsLiteralConstDeclaration returns false when the declaration's type is a non-enum number literal whose value is Infinity, -Infinity or NaN, so the declaration gets a type annotation instead of an initializer.
• CreateLiteralConstValue returns nil for those values. The export default path calls it directly and already falls back to a type annotation on nil. This replaces the branches that built the Infinity and NaN identifiers, which produced exactly the invalid initializers above.

Output after the fix:

export declare const a: number;
export declare const b: number;
export declare class C {
    static readonly e: number;
}
declare const _default: number;
export default _default;

Enum members with NaN or Infinity values are unaffected (declarationEmitEnumNaN.ts). So are references to them: export const g = E.A still emits = E.A, which is a valid initializer.

An alternative would be to reuse the source text (= 1e400), which keeps the literal type. It needs a fallback anyway, since the type can come from an expression that isn't a numeric literal. I went with number to keep the change small. Happy to switch if you prefer.

Related: #42905 (Infinity in type positions, fixed in 7.1) and #63831 (-1e500 as const emitted as -Infinity). The type-position case in #63831 goes through the node builder and isn't touched here. #56272 discusses whether overflowing literals should have an Infinity literal type at all. This fix doesn't depend on that outcome: either way, the emitted .d.ts must type-check.

Tests

• New compiler test declarationEmitNonFiniteNumberLiteral.ts. It covers const, negative values, the smallest overflowing literal (1.7976931348623159e308), a large finite literal that must keep its value (1e308), static readonly and readonly properties, export default, and references to NaN and Infinity enum members. Without the fix, the harness's .d.ts re-check records 6 TS1254 errors (//// [DtsFileErrors]). With it, there are none.
• Every other declarationEmit*, enum, fakeInfinity1 and nanEquality compiler test is unchanged (599 tests).
• go test ./... in tsc passes: 64 packages, no failures (golang:1-bookworm in Docker). internal/testrunner was run on its own with -parallel 4, because the Docker VM's 4 GB ran o