Fix discriminated union inference ordering issue with flatMap

[Copilot]

getSingleCommonSupertype picks the wrong inference candidate when neither of two candidates is a strict supertype of the other, because union constituent ordering differs between the Go and JS compilers — causing them to break ties inconsistently and produce diverging results for the same code (e.g. a discriminated union callback passed to Array.prototype.flatMap).

Root cause

A prior fix attempt (backported in #63328 from typescript-go#3301) addressed this by replacing the subtype-based tiebreak in getSingleCommonSupertype with a blanket assignability check. This resolved the reported case but regressed real-world code (an Inquirer.js deep-merge/theme-typing pattern), since asymmetric assignability isn't a sound universal tiebreaker — it can favor an overly loose candidate whenever candidates differ only in property optionality.

Digging further, the actual root cause is narrower: propertiesRelatedTo's requireOptionalProperties check is relaxed only for object literal types, but candidate literal types lose their "object literal" flag once widened during inference candidate collection — incorrectly subjecting them to the stricter rule meant only for non-literal types.

Fix

• Leave getSingleCommonSupertype's tiebreak untouched (still subtype-based), avoiding the previously-observed regression.
• Add ObjectFlagsWidenedObjectLiteral, retained on types produced by getWidenedTypeOfObjectLiteral when their pre-widening origin was an object literal.
• Relax requireOptionalProperties in propertiesRelatedTo to also treat such widened types leniently, matching the treatment they'd receive before widening.

export type InputOp = { op: "add" } | { op: "remove"; value?: Array<unknown> };
export type OutputOp = { op: "add" | "remove" };

export function f(operations: InputOp[]): OutputOp[] {
  return operations.flatMap((operation) => {
    if (operation.op === "remove" && operation.value) {
      return [].map(() => ({ op: "remove" })); // no longer errors
    } else {
      return [operation];
    }
  });
}

Added a compiler test (discriminatedUnionFlatMap.ts) covering the reported scenario.

• Fixes Inconsistency involving discriminated union and flatMap #63776