fix: support @Module.Const syntax in expressions

[engalar]

Fixes #178

Summary

• Added @QualifiedName as a valid atomicExpression in the MDL grammar for constant references
• New ConstantRefExpr AST node type for clean representation
• Visitor converts @ Module.Const parse tree to ConstantRefExpr
• expressionToString() outputs @Module.Const for BSON serialization
• Backward compatible: getConstantValue('Module.Const') still works

Round-trip restored

-- DESCRIBE outputs:
DECLARE $val String = @MyModule.MyConstant;

-- Can now be fed back into CREATE without modification ✓

Test plan

• mxcli check accepts @Module.Const syntax
• mxcli check still accepts getConstantValue('Module.Const') syntax
• Full test suite passes
• Build succeeds

[ako]

Surgical, minimal fix that restores DESCRIBE roundtrip for microflows referencing constants.

What's good

• Full-stack change in 5 files: 1 grammar line, 1 AST type, 1 visitor case, 2 formatter cases
• Backward compatible — getConstantValue('Mod.Const') still works
• Reuses existing AT token (no lexer changes)

Concerns

Potential parser ambiguity with @annotation. The grammar already uses AT IDENTIFIER for annotations like @Documentation. Adding AT qualifiedName to atomicExpression should be fine since contexts don't overlap (annotations are statement-level, expressions are body-level), but a test confirming this would close the gap.

No regression tests. The PR's main value is DESCRIBE roundtrip but there's no test verifying parse → describe → re-parse for a microflow with @Module.Const. A doctype-test entry would prevent regression.

Two expressionToString functions in different files both got the new case. This kind of duplication is a maintenance hazard but outside the scope of this PR.

QualifiedNameExpr change in cmd_diff_mdl.go is unrelated to the constant reference fix — looks like a separate bug being piggybacked. Should be its own commit ideally.

LGTM.