fix(cue): accept '-' and '.' in variable references

[s3onghyun]

What / Why

Fixes the validation side of perses/perses#4327.

A datasource can reference a variable by name (datasource: "$myVar"). The reference is validated in cue/common/datasource.cue against #variableSyntaxRegex, which was "^\\$\\w+$" — i.e. $ followed by word characters only.

But a variable name is allowed to contain - and . (the name rule is "^[a-zA-Z0-9_.-]+$"). So a perfectly valid variable such as my-datasource can be created, yet referencing it as $my-datasource fails CUE validation:

invalid value "$my-datasource" (out of bound =~"^\$\w+$")

which is exactly the error reported in perses/perses#4327 (reproduced on v0.54.0).

Change

Widen #variableSyntaxRegex so the reference character set matches the variable name rule:

- #variableSyntaxRegex: "^\\$\\w+$"
+ #variableSyntaxRegex: "^\\$[a-zA-Z0-9_.-]+$"

This is not a breaking change: #variableSyntaxRegex is an anchored full-match validator (^…$) on the datasource field value, so widening it only accepts more strings — nothing that validated before stops validating. Because it's a full-match validator (not an extraction regex over a larger string), there's no greedy-match ambiguity here.

Tests

Added regression cases to cue-test/common/datasource.cue for $ds-var and $ds.var. Verified with make test-cue:

• before the fix, both new cases fail with out of bound =~"^\$\w+$" (reproducing the bug);
• after the fix, the package validates cleanly;
• a reference that isn't a valid name either (e.g. $ds/var) is still rejected, so the set isn't over-widened.

Scope note

The report's root cause is a mismatch between the name rule and the reference grammar. This PR fixes the CUE validator, which is what produces the user-visible error. There is a second, independent reference parser in the main repo — variableSyntaxRegexp (\$(\w+)) in pkg/model/api/v1/utils/variable_build_order.go, used for dependency ordering. Widening that one needs more care because it extracts from arbitrary query strings and deliberately skips purely-numeric matches to avoid colliding with PromQL positional refs ($1, $2); a naive [\w.-]+ there would capture things like $1-foo. I'm happy to do that as a separate follow-up in perses/perses if you'd like it kept consistent.

cc @Nexucis — @Labiote endorsed the non-breaking direction on the issue and asked for your confirmation; opening this as the concrete proposal.