Implement the generic FSharp2 batch compiler pipeline

Outcome

Implement the independently authored FSharp2 batch compiler pipeline behind the compatible command-line and MSBuild surfaces. The existing issue #8 prototype is prior evidence and reusable scaffolding, not the production compiler architecture or language boundary.

The measured prototype result in .agents/docs/research/minimum-fsharp2-prototype-result.md answered the original tracer question negatively: it validated the NativeAOT host, MSBuild selection, retained-service seam, synthetic symbolic linker, transactional publication, and synthetic emitted-output gate, but it did not compile the declared real-world corpus. Later construct-by-construct commits do not change that boundary.

Corpus-neutral acceptance policy

• Production code must not recognize IcedTasks paths, namespaces, types, members, target frameworks, source order, or expected failure locations.
• Primary tests are organized by F# language construct and observable compiler behavior.
• Every supported construct has small positive and negative Compatibility Oracle cases.
• Reaching the next file or error in an external corpus is progress evidence, never ticket completion.
• Unsupported experimental inputs fail explicitly; the official compiler and FSharp.Compiler.Service never provide production fallback.
• External projects are end-to-end integration corpora. They may reveal missing generic behavior but may not define compiler module interfaces.
• Tests cross durable compiler-module interfaces and do not expose internals only to make a corpus-shaped test pass.

Work breakdown

Foundation

1. #25 — compiler request, result, and phase contracts
2. #26 — differential harness and generic conformance manifest
3. #27 — diagnostic policy and compatibility

Frontend and semantic inputs

4. #28 — source text, lexing, directives, and layout
5. #29 — immutable syntax trees and parser recovery
6. #30 — metadata-only target-reference and F# signature import

Semantics and reusable typed state

7. #31 — symbols, scopes, signatures, and name resolution
8. #32 — core inference, unification, and generalization
9. #33 — F# types, members, overloads, and constraints
10. #34 — typed checkpoints and semantic fingerprints

Lowering and emission

11. #35 — core language lowering
12. #36 — computation expressions, sequences, quotations, and resumable code
13. #37 — compatible optimization, debug, and tail-call modes
14. #38 — generic ECMA-335 metadata and IL emission
15. #39 — F# metadata and companion build/debug artifacts

Integration and evidence

16. #40 — batch compiler, MSBuild, and transactional artifact contract
17. #41 — declaration-granular incremental compilation and reusable state
18. #42 — first Experimental Vertical Milestone

GitHub sub-issue relationships are canonical. The dependency lines in each child define the intended implementation waves.

Definition of done

• Every child issue is complete against compiler-owned conformance programs and its declared Compatibility Oracle evidence.
• Standalone, persistent-service, command-line, and MSBuild paths share the same compiler semantics and produce equivalent observable results.
• Supported inputs traverse parsing, resolution, typing, lowering, optimization, emission, publication, loading, and execution without fallback.
• The first real-world milestone passes only after generic subsystem gates pass.
• Governed performance infrastructure remains #24; it admits timings only after compiler correctness.

Outside this workstream

FSharp.Compiler.Service API compatibility, F# Interactive and script execution, the Provider Broker implementation, full cross-platform release packaging, secure hosted evidence storage, and the remaining final Compatibility Gate expansion remain siblings or future children of #1.