fix(sentry): Upload and use source maps for all build targets

[BYK]

Summary

This PR fixes source map generation, upload, and runtime association across all build targets to ensure proper error stack trace symbolication in Sentry.

Changes

• Release name consistency: Fixed mismatch between build-time (4.9.0) and runtime ([email protected]) formats
• Electron renderer source maps: Added Sentry plugin to upload source maps for renderer process (was only configured for main process)
• Fossilized binaries: Injected version constant at build time so CLI/Docker builds have correct release matching
• Source map cleanup: Added filesToDeleteAfterUpload to remove source maps after upload
• Consistent release naming: Updated Electron renderer to use sentryBaseConfig for consistent release format

Impact

Fixes source map symbolication for:

• Electron app (main + renderer processes)
• CLI/npx runs
• Docker images
• Fossilized standalone binaries
• MCP server (inherits CLI fixes)

Evidence

Verified source map issues in Sentry:

• SPOTLIGHT-A2: CLI errors showing unsymbolicated dist/server/cli/mcp.js paths
• SPOTLIGHT-7H: Electron renderer showing minified function names (s, F4, k4)

After this fix, errors will show original TypeScript source paths and proper line numbers.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
spotlightjs	Skipped		Jan 8, 2026 1:05am

[BYK]

I guess this is redundant now then? Or __SPOTLIGHT_VERSION__ was never needed. Which one?

[BYK]

Both are needed for different scenarios:

• __SPOTLIGHT_VERSION__: Injected at build time via Vite define, so it's baked into the code and available everywhere, including fossilized binaries (CLI/Docker standalone executables) where process.env.npm_package_version is undefined
• process.env.npm_package_version: Available at runtime for npm/npx runs, but not in fossilized binaries

The code in sentry-config.ts prefers __SPOTLIGHT_VERSION__ but falls back to process.env.npm_package_version as a safety net. This ensures:

1. Fossilized binaries work (they only have __SPOTLIGHT_VERSION__)
2. npm/npx runs work (both available, but __SPOTLIGHT_VERSION__ takes precedence)
3. Development builds work (fallback to env var)

We keep process.env.npm_package_version in defineProduction because other parts of the codebase may reference it directly, not just Sentry.

[BYK]

Responding to review comment on line 15:

Both are needed for different scenarios:

• __SPOTLIGHT_VERSION__: Injected at build time via Vite define, so it's baked into the code and available everywhere, including fossilized binaries (CLI/Docker standalone executables) where process.env.npm_package_version is undefined
• process.env.npm_package_version: Available at runtime for npm/npx runs, but not in fossilized binaries

The code in sentry-config.ts prefers __SPOTLIGHT_VERSION__ but falls back to process.env.npm_package_version as a safety net. This ensures:

1. Fossilized binaries work (they only have __SPOTLIGHT_VERSION__)
2. npm/npx runs work (both available, but __SPOTLIGHT_VERSION__ takes precedence)
3. Development builds work (fallback to env var)

We keep process.env.npm_package_version in defineProduction because other parts of the codebase may reference it directly, not just Sentry.

[BYK]

Yay, look at me talking to myself online