web: pass Ctrl-= through to browser for font size increase

[Copilot]

Ctrl-= (the no-Shift convention for Ctrl-plus) was intercepted by SolveSpace's canvas zoom-in handler, blocking the browser from using it to increase font size. Ctrl-minus already passed through unblocked because the ZOOM_OUT accelerator is bound to bare - (no Ctrl), so the match failed and EM_FALSE was returned — but Ctrl-= had a special-case handler in GraphicsWindow::KeyboardEvent that matched regardless of Ctrl state.

Change

Added an early-exit in KeyboardCallback (guihtml.cpp) before any event processing:

// Pass Ctrl-= through to the browser (for font size increase), symmetric with
// Ctrl-minus which is already passed through since it doesn't match any shortcut.
if(emEvent->ctrlKey && strcmp(emEvent->key, "=") == 0) return EM_FALSE;

= without Ctrl continues to trigger canvas zoom-in as before.

[phkahler]

@copilot Why do you think CTRL - works but CRTL = need this change?

[Copilot]

@copilot Why do you think CTRL - works but CRTL = need this change?

The difference is in how each key is handled inside GraphicsWindow::KeyboardEvent:

Ctrl-minus: The ZOOM_OUT accelerator is bound to bare '-' (no Ctrl). When Ctrl-minus arrives, event.controlDown = true, so it doesn't match the accelerator (which expects controlDown = false). No handler claims it → KeyboardEvent returns false → KeyboardCallback returns EM_FALSE → browser sees it and decreases font size. ✓

Ctrl-=: There's a special-case handler at graphicswin.cpp:249 that matches event.chr == '=' without checking controlDown:

} else if(event.chr == '=') {
    // Treat = as +.
    MenuView(Command::ZOOM_IN);
    return true;
}

This fires for both bare = and Ctrl-=, returning true both times. So KeyboardCallback returns EM_TRUE → the browser never sees Ctrl-= → font size increase is blocked. ✗

The fix in guihtml.cpp short-circuits before the event even reaches GraphicsWindow::KeyboardEvent when Ctrl-= is pressed, letting the browser handle it.