fix: parse negative annotation coordinates

[hjotha]

Closes #493.

Summary

• preserves signed integer values in annotation parameters such as @position(-150, -210)
• keeps the existing literal-only fallback for non-signed numeric annotation parameters
• adds a synthetic microflow visitor regression test for negative coordinates

Validation

• go test ./mdl/visitor -run 'NegativeCoordinates|PositionAnnotation' -v
• make build
• make lint-go
• make test

[ako]

Review: fix: parse negative annotation coordinates

Verdict: Approve

What the PR does

Fixes issue #493: @position(-150, -210) annotations were silently returning 0 for both coordinates. The existing parseAnnotationParamInt only followed the Literal → NUMBER_LITERAL path, which doesn't match negative numbers. A value like -150 is parsed by the grammar through the expression rule (unary minus + integer), so annValue.Literal() returns nil and the function fell through to return 0.

The fix calls strconv.Atoi(strings.TrimSpace(valueCtx.GetText())) first — ANTLR's GetText() concatenates all child token texts, producing "-150" for the expression case — then keeps the existing literal fallback path for any value Atoi can't handle.

No blockers

Minor observation

The TrimSpace call handles leading/trailing whitespace on the raw text, but not intra-token whitespace like - 150 (space between minus and digits). That would cause Atoi to fail and fall through to the literal path, returning 0. In practice annotation params written with - 150 are unlikely, and the expression grammar rule lexes -150 without intermediate whitespace. Worth a brief comment if this code is touched again, but not a blocker.

Positive notes

• Minimal, focused fix — 3 lines of production code, no grammar change required
• New test directly reproduces the bug and asserts exact coordinate values
• The early-return structure is correct: positive integers now also hit the Atoi fast path (same result as the literal path), which is harmless
• Clean PR, no bundled unrelated changes