v0.1.0 — parser, semantic IR, and native compilation

First tagged release. Phases 1–2 of the roadmap are complete: .lnpl parses, lowers to a semantic
IR, and runs both on the IR interpreter and as a native binary.

What works

• Language + semantic IR — .lnpl source parses and lowers to the IR described in RFC-0001.
• Mode A — IR interpreter. The reference implementation executes the golden scenario end to end.
• Mode B — native compilation. The same IR compiles through MLIR to a native binary.
• Differential verification. A differential check compares modes A and B on the four observable
  classes RFC-0004 names — execution order, policy outcome, observability signals, masking — and is
  proven able to go red by a deliberate-mismatch case. It reports EQUIVALENT on the golden
  scenario; see Known limitations for where the two modes do diverge.
• Guard conditions. when comparison guards are evaluated at runtime in both modes, with
  condition-field values passed to the binary as arguments (RFC-0008 G8).
• OpenAPI generation. The spec is generated from the IR rather than hand-maintained — and so is
  the golden scenario itself.
• 264 tests passing.

RFCs

Eight RFCs, all Accepted:

RFC	Title
0000	RFC process
0001	Semantic IR
0002	Syntax
0003	Runtime
0004	Compiler
0005	Knowledge base
0006	Agent protocol
0007	RFC process v2
0008	Guard conditions

RFC bodies are written in Korean; identifiers, keywords, and schema fields are English.

Known limitations

• until is not evaluated at runtime in mode B. It is statically unrolled to
  _UNTIL_ROUND_CAP (16), so once the condition holds the two modes diverge: with
  until counter >= 10, mode A runs 0 iterations at counter = 10 while mode B still runs 16. The
  differential check's EQUIVALENT result therefore covers the golden scenario's range, not every
  payload. Fixed after this tag in #5; the
  remaining part of issue #3 is the guard
  condition grammar, which still admits phrases no evaluator implements.
• RFC-0008 G8's condition-field plumbing is only correct for two condition fields at this tag.
  lnpl_run's parameters were derived independently in three places, so a workflow with a different
  number of condition fields, or a payload carrying an unrelated integer, could silently take the
  wrong guard branch with exit code 0. The CLI's build --run never forwarded values at all.
  Fixed after this tag in #4; if you are evaluating
  guard conditions, build from main rather than from v0.1.0.

Not in this release

Phase 3 — a custom lnpl MLIR dialect — is not started. It needs C++ TableGen; tracked in
issue #1.

See the roadmap for what comes next.