Good fix overall — the deeper bundle check (Contents/MacOS/ + Info.plist), the void → bool return, and the UI reset in the daxToggled path are all the right calls. Two things worth addressing before merge:

1. Menu-action path doesn't reset its check state on failure (buildMenuBar)

The daxToggled lambda correctly calls setDaxEnabled(false) when startDax() returns false, but the menu-action lambda only acts on success:

// buildMenuBar (current)
if (on) {
    if (startDax() && m_appletPanel && m_appletPanel->catApplet())
        m_appletPanel->catApplet()->setDaxEnabled(true);
    // no else — menu item stays checked, catApplet stays unchecked → inconsistent
}

Suggested fix — mirror the daxToggled path:

if (on) {
    if (startDax()) {
        if (m_appletPanel && m_appletPanel->catApplet())
            m_appletPanel->catApplet()->setDaxEnabled(true);
    } else {
        // uncheck the menu action and keep catApplet consistent
        sender()->setProperty("checked", false);  // or keep a captured QAction* ref
        if (m_appletPanel && m_appletPanel->catApplet())
            m_appletPanel->catApplet()->setDaxEnabled(false);
    }
}

(Exact reset depends on whether the menu action reference is captured in the lambda — the point is to uncheck it and sync the catApplet.)

2. QMessageBox::warning fires during silent autostart

onConnectionStateChanged calls startDax() inside a 3-second QTimer::singleShot when AutoStartDAX is enabled. With the new dialog, every time the user connects on a Mac without the driver installed they'll get a blocking warning 3 seconds after the connection completes — even though they never explicitly asked to enable DAX in that session.

Consider suppressing the dialog in that path and logging at qWarning() instead (the user can investigate from the log). The dialog is appropriate for an explicit toggle action, but it's jarring as a side-effect of connecting.

No other concerns. Scope is tight (only MainWindow.cpp/.h), AppSettings usage is correct (the path constants are read-only via QFileInfo), and there are no resource leaks in the m_daxBridge failure path. Thanks for the contribution @jensenpat.