fix(packaging): bundle certifi CA bundle in PyInstaller binary

[not-knope]

Summary

• Bundle certifi's cacert.pem in the PyInstaller build (collect_data_files('certifi')) and set SSL_CERT_FILE / REQUESTS_CA_BUNDLE via a runtime hook (plus a frozen-entry safety net in strix/interface/main.py), fixing TLS failures that surfaced as generic LLM Connection error on macOS Apple Silicon standalone binaries.
• Attach an early stderr logging handler before warm_up_llm() so STRIX_DEBUG=1 actually shows preflight failures, and print the full exception cause chain in the connection-error panel when debug is on.

Fixes #1008

Test plan

• uv run python -c "import certifi; print(certifi.where())"
• Confirm strix.spec contains collect_data_files('certifi') and runtime_hooks=[...pyi_rth_certifi.py]
• Confirm PyInstaller collect_data_files('certifi') includes cacert.pem
• uv run pytest tests/test_preflight_logging.py tests/test_packaging.py tests/test_provider_hints.py
• Rebuild standalone binary and verify LLM preflight succeeds on macOS Apple Silicon with a valid API key
• With a broken CA path scenario (or forced TLS failure), confirm STRIX_DEBUG=1 prints warm-up debug + root SSL cause

[greptile-apps]

Greptile Summary

The PR bundles certifi’s CA data into PyInstaller builds, configures frozen executables to use that bundle, and improves diagnostics for early LLM connection failures.

• Adds a certifi runtime hook and corresponding PyInstaller data collection.
• Adds preflight stderr logging and debug-mode exception-chain details.
• Adds packaging and preflight-logging tests.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking logging lifecycle issue that duplicates scan output after a successful preflight.

The CA-bundle and diagnostic changes have no established blocking failure, but the newly attached preflight handler coexists with scan-scoped stderr logging and is never removed.

Files Needing Attention: strix/telemetry/logging.py

Important Files Changed

Filename	Overview
hooks/rthooks/pyi_rth_certifi.py	Exports the bundled certifi path for frozen processes while preserving explicit environment overrides.
strix.spec	Collects certifi data and registers the new PyInstaller runtime hook.
strix/interface/main.py	Adds a frozen-entry CA fallback, richer debug connection details, and early preflight logging setup.
strix/telemetry/logging.py	Adds debug-mode resolution and a preflight handler, but leaves that handler attached when scan logging starts.
tests/test_packaging.py	Adds static checks for certifi data collection and runtime-hook configuration.
tests/test_preflight_logging.py	Covers exception-chain formatting, debug environment parsing, and early stderr output.

Prompt To Fix All With AI

### Issue 1
strix/telemetry/logging.py:163-165
**Preflight handler persists into scans**

After a successful non-interactive preflight, `setup_scan_logging()` adds another stderr handler to the same logger roots without removing this preflight handler. Scan records are consequently printed twice, and the preflight handler remains attached after scan teardown.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(packaging): bundle certifi CA bundle..." | Re-trigger Greptile}

[greptile-apps]

Preflight handler persists into scans

After a successful non-interactive preflight, setup_scan_logging() adds another stderr handler to the same logger roots without removing this preflight handler. Scan records are consequently printed twice, and the preflight handler remains attached after scan teardown.

Knowledge Base Used:

• CLI and Runner: from strix invocation to a running scan
• Configuration and Telemetry

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/telemetry/logging.py
Line: 163-165

Comment:
**Preflight handler persists into scans**

After a successful non-interactive preflight, `setup_scan_logging()` adds another stderr handler to the same logger roots without removing this preflight handler. Scan records are consequently printed twice, and the preflight handler remains attached after scan teardown.

**Knowledge Base Used:**
- [CLI and Runner: from `strix` invocation to a running scan](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/cli-and-runner.md)
- [Configuration and Telemetry](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/telemetry-and-config.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.