Fix undefined behavior from front() on empty token deque in SquelchCombine parser

[MarkRose]

The SQL_COMBINE expression parser in SquelchCombine.cpp called
std::deque::front() on m_tokens without first checking that the deque was
non-empty, which is undefined behavior (typically a crash) rather than a
clean configuration error.

• parseUnaryOpExpression() checked m_tokens.front() == "!" as its very
  first statement, before parseInstExpression()'s empty-deque guard ever
  runs. An empty or whitespace-only SQL_COMBINE value tokenizes to an empty
  deque, so this is hit immediately during initialize().
• parseInstExpression() checked m_tokens.front() != ")" after parsing a
  parenthesized sub-expression, without verifying a closing paren token
  still remained. An unbalanced-parenthesis expression such as "(a" leaves
  the deque empty at that point, triggering the same undefined behavior.

Both call sites now go through a new local helper, tokenFrontIs(), that
safely returns false when the deque is empty instead of dereferencing
front(), so malformed SQL_COMBINE values are now rejected with the
existing error-reporting/parse-failure path instead of crashing.

Co-Authored-By: Claude Opus 4.8 [email protected]