fix(parser,types): clear the ParseError long tail + Cluster A logical-assignment narrowing

[nickna]

Summary

Follow-up to #1259 (merged) — continuation of epic #99 / #80 Track-1 (TS conformance). #1259 was merged before this branch's later commits were pushed, so this PR carries the remainder, across two pieces of work:

1. Clearing the ParseError long tail (7 tests)

Seven unrelated, independently-scoped parser gaps found while clearing what was left of the ParseError bucket:

• Object-type/interface members separated only by a newline (no ;/,) now use the same ASI fallback as top-level interface members (bar(): { baz: T } followed by baz: T on the next line).
• A parenthesized member/index expression is a valid assignment target for =, compound, and logical-assignment operators alike ((a.b) &&= v) — parens don't change whether an expression is a reference; unwrap them (recursively) before dispatch.
• async is a contextual keyword, not exclusively a function/arrow marker: only commit to parsing an async function/arrow when it's immediately followed by function/</(; otherwise treat it as a plain identifier reference (if (async), a destructured async binding).
• import.meta used as a statement (import.meta.foo();) was routed to the static import-declaration parser because the statement dispatcher only excluded dynamic-import's import(, not import. — both are expressions, not declarations.
• export { x as y } (a bare specifier list, no declaration) inside declare global/declare module bodies was unhandled — only export <declaration> forms were.
• export * as ns from './mod' (ES2020 namespace re-export) wasn't recognized; only bare export * from was.
• An untagged template with an invalid escape sequence (`\xtraordinary`) is a real syntax error (TS1125) but a recoverable one — tsc keeps checking the rest of the file. The parser now substitutes an empty string for that part and records the offending line(s) instead of aborting the parse; the checker reports TS1125 there. Tagged templates are unaffected.

2. Cluster A: compound logical-assignment narrowing (logicalAssignment4/11)

Three gaps in CheckLogicalAssign / the if-condition type-guard analyzer, all needed together:

• Post-assignment narrowing: results ||= []; results.push(100) (statement form) wasn't narrowed for the second statement — CheckLogicalAssign now installs the assignment's result type into the environment the same way CheckAssign already does for plain x = v.
• &&= short-circuit narrowing within its own RHS: thing &&= thing.original spuriously flagged thing as possibly undefined on a read &&='s own short-circuit already guarantees is safe — narrow the LHS to truthy while checking the RHS, mirroring plain &&.
• if (x OP= y) as a type-guard condition (new AnalyzeLogicalAssignGuard): the LHS narrows like a bare if (x); for &&= specifically, a truthy result additionally proves the RHS ran and was itself truthy, so a bare-identifier RHS narrows too (verified against tsc's own baseline — ||=/??= do NOT get this).
• Also fixes a real pre-existing bug surfaced along the way: the "pick the wider of two candidate types" pattern in CheckLogicalAssign's result-type computation had its two IsCompatible branches' return values swapped, collapsing a union to its narrower constituent instead of the wider one.

Not fixed, left as separate follow-ups (distinct root causes from narrowing): logicalAssignment5 needs a new checker feature — TS2722 "cannot invoke an object which is possibly undefined" doesn't exist anywhere in the codebase. logicalAssignment6/7 need argument-compatibility checking to continue after a nullable-receiver diagnostic fires, instead of stopping there.

Result: TS conformance subset baseline 203 → 211 Pass, 7 → 0 ParseError, 0 regressions across both pieces of work.

Test plan

• dotnet test (SharpTS.Tests) — 15452/15452 passing
• SharpTS.Test262 interpreted + compiled baselines — 0 failures
• SharpTS.TypeScriptConformance baseline — 211 Pass / 69 Fail / 0 ParseError / 17 Skipped / 1 TypeCheckError, 0 regressions vs. committed baseline