#10717: fix: skip response prefix with unresolved template variables in routeReply

## Summary - When `routeReply` applies a `responsePrefix` containing template variables like `{model}`, it has no `ResponsePrefixContext` available to resolve them - This causes raw template text (e.g. `[{model}]`) to appear in routed messages instead of being omitted - Fix: use `hasTemplateVariables()` to detect unresolvable templates and skip the prefix entirely in that case ## Test plan - [x] Added test: `skips responsePrefix containing unresolved template variables` - [x] All 17 route-reply tests pass - [x] Static prefix like `[openclaw]` continues to work as before Closes #10672 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> - Updates `routeReply()` to avoid applying `messages.responsePrefix` when it contains template variables (e.g. `{model}`), since route routing doesn’t have a `ResponsePrefixContext` to resolve them. - Adds a regression test ensuring a templated prefix like `[{model}]` is omitted (message text remains unchanged) while static prefixes still apply. - Implements the behavior by calling `hasTemplateVariables()` from the existing response prefix templating utility and passing `undefined` to `normalizeReplyPayload` when templates are detected. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - Change is small, localized to `routeReply`, relies on an existing well-tested utility (`hasTemplateVariables`), and includes a regression test that captures the reported failure mode (templated prefixes leaking raw `{model}` text). No behavior changes for static prefixes, and the skip only triggers when template braces are present. - No files require special attention <!-- greptile_other_comments_section --> <!-- /greptile_comment -->