Editor grammar under-accepts 4 renderer-valid constructs (async / loop / @Starter-arg / method-arg literals)

[MrCoder]

Summary

A grammar-gap hunt (editor Lezer parser vs renderer ANTLR parser) found 4 more
renderer-valid constructs the editor grammar rejects. Each is a false positive that
breaks highlighting/completion today and blocks wiring the in-editor error linter
(web/src/editor/modes.ts). Verified: ANTLR parses each with 0 errors; Lezer errors.

Construct	Example	Lezer	ANTLR
async message prefix	async A->B: msg	ERROR	ok
loop keyword (synonym of while)	loop (3) {\n A.b()\n}	ERROR	ok
@Starter(arg) then a statement	@Starter(A)\nA.b()	ERROR	ok
method-call literal args	A.b(1, "two", true)	ERROR (5)	ok

Location

web/src/editor/grammar/zenuml.grammar:

• async: AsyncKeyword exists (~116) but the message rule doesn't accept an async
  prefix on A->B.
• loop: Loop { !statement WhileKeyword Condition StatementBraceBlock } (~364) — only
  while; needs a loop keyword (@Specialize) alternative.
• @Starter(arg): StarterExp (~150) parses @Starter(A) alone but errors when a
  statement follows — likely a Head-termination / expression-boundary issue.
• args: Parameters/Parameter/Atom (~287, 348) don't accept the full literal set
  (number/string/boolean) as call arguments.

Fix

Close each gap so the editor accepts what the renderer accepts. Gate on the new
src/editor/conformance/noFalsePositive.test.ts (every renderer-valid input → 0 Lezer
error nodes) plus the existing conformance corpus (participants ⊆ oracle). Regenerate the
parser. This (with #810, quoted method names) clears the modes.ts false-positive blockers
toward enabling error feedback.

Found via the editor-improvement campaign (grammar-gap hunt).