`x(0) == v` with `v` the variable reports `UndefVarError: `v##NNNN` not defined in `Main`` instead of a clear message

## Context

Found while making OptimalControl's `docs/src/modelling/abstract-syntax.md` executable
(control-toolbox/OptimalControl.jl#913). The page documents the rule *"constraint bounds
must be effective, that is must not depend on a variable"* and shows a rejected example.
The example **is** rejected — but with an internal-gensym `UndefVarError` that tells the
reader nothing about the cause.

## Reproduce

```julia
using OptimalControl # CTParser 0.9.4-beta, CTBase 0.30.2-beta, CTModels 0.19.2-beta

@def begin
v ∈ R, variable
t ∈ [0, 1], time
x ∈ R², state
u ∈ R, control
-1 ≤ v ≤ 1
x₁(0) == -1
x₂(0) == v # a boundary "bound" that references the variable
x(1) == [0, 0]
ẋ(t) == [x₂(t), u(t)]
∫(0.5u(t)^2) → min
end
```

Result:

```
Line 7: x₂(0) == v
UndefVarError: `v##3260` not defined in `Main`
Suggestion: check for spelling errors or missing imports.
```

The `v##3260` is a leaked internal gensym for the variable vector; it is referenced in
generated boundary-constraint code but is not in scope there.

## Expected

A `ParsingError` (or similar) naming the real cause — e.g. *"a constraint bound may not
depend on the variable `v`; write it as a boundary constraint instead, e.g. `x₂(0) - v == 0`"*.
The working form `x₂(0) - v == 0` builds fine.

## Impact

Low severity (the construct is rejected, just unhelpfully), but the message is user-facing
and currently misleading. OptimalControl#913 works around it by softening the doc prose;
this issue tracks the real fix.