fix: handle operators after brace initialization - #474

Reviewed head 15836727ece29678e2be254e34d7acaf47008cfb against
862844602d3b30731a36b15965360e576adf7ec9.

The original #373 false positive is fixed, but the new
operator_after_braced_value exception also suppresses valid block-spacing
diagnostics.

At cpplint.py:4748–4751, a word at the end of leading_text is not sufficient
to identify a braced value: it also accepts else, mutable, and noexcept.
For example:

int ElseBlock(int value) {
  if (value > 0) {
    --value;
  } else{
    value = 0;
  }
  ++value;
  return value;
}

bool MutableLambda() {
  return []() mutable{ return 1; } == nullptr;
}

bool NoexceptLambda() {
  return []() noexcept{ return 1; } == nullptr;
}

All three missing spaces are reported by the base and silently accepted by this
head. The else case also shows that an operator starting a subsequent statement
can trigger the new exception.

I verified this with Python 3.12.14 using the actual base/head cpplint CLI and
--filter=-,+whitespace/braces. A combined file containing these cases plus the
original std::optional{pmr_string{a} + " " + b} shape gives four warnings on the
base and none on the head; the expected result is three warnings. The complete
reproducer also passes g++ -std=c++20 -fsyntax-only with GCC 13.3.

Please preserve block/lambda diagnostics before accepting the operator
continuation, including keyword-ended contexts, and add these negative controls
alongside the initializer regression tests.

The PR's Actions run is green. I did not run the full pytest suite locally because
pytest is unavailable in this environment; the comparison above is an independent
CLI reproduction.