return inside changes template silently exits callback body instead of proc

[dsrw]

Summary

Using return inside a changes callback body silently exits only the callback body rather than the enclosing proc. This causes subtle bugs where code after the return is never reached, but no error or warning is raised.

Example

state.some_value.changes:
  if not condition:
    return  # intended to skip processing, but may not behave as expected
  # ... rest of handler

In practice, we had a changes(false) callback (pause disabled) where a top-level if not added: return was silently swallowing the callback re-invocations triggered by setting the value inside the callback. The return appeared to work for the initial call but the re-triggered callbacks never produced the expected side effects, causing a 10s timeout waiting for a response that never came.

Removing the return and restructuring as if added: ... fixed the issue.

Expected behavior

Either:

1. return inside a changes body should return from the enclosing proc (consistent with how Nim templates typically work when the body is inlined), or
2. A compile-time error should be raised if return is used inside a changes body, since the semantics are likely not what the user expects.

Notes

This may be intentional if the changes macro/template wraps the body in a proc or closure — in that case a compile error with a helpful message ("use break or restructure with if instead of return") would prevent confusing bugs.

[dsrw]

Fixed by adding a check_no_return passthrough macro that's called from inside the changes template body. It walks the AST for bare return statements (skipping nested proc/func/lambda definitions) and emits a compile error pointing at the offending line. The changes template itself is unchanged — no performance impact.