Enhanced Exception Context for Background Connection Debugging

## Parent Epic
Part of #39102

## Description

Improve Sentry error reporting for background connection failures by switching to structured exception reporting with proper source map support.

**From source documentation**:
- Switch to `exception` property for error reporting
- Enable source maps for proper stack trace resolution
- Add `culprit` tag (normalized file path)

## Current State

- Background connection errors currently reported with limited context
- Source maps not properly resolved in Sentry
- Difficult to trace exact failure points

## Proposed Changes

1. **Switch to Exception Property**
- Change from plain error message to structured exception
- Preserve original error stack traces

2. **Enable Source Map Resolution**
- Ensure `dist` tag is properly set (mv2/mv3)
- Verify source map uploads in CI/CD

3. **Add `culprit` Tag**
- Enable filtering by error source

## Testing Requirements

- [ ] Verify source maps resolve in Sentry
- [ ] Confirm stack traces show correct line numbers
- [ ] Validate `culprit` tag appears in all events
- [ ] Test with both MV2 and MV3 builds

## Success Criteria

- 100% of new background connection errors have resolved stack traces
- Source locations point to actual source files (not minified)
- `culprit` tag present in all events
- Exception cause chain preserved

## References

- **Known Location**: `ui/helpers/utils/critical-startup-error-handler.ts:62:22` (from Sentry data)

Start at ui/helpers/utils/critical-startup-error-handler.ts:62:22 and trace how background connection failures are sent to Sentry. Then inspect the MV2/MV3 build and CI source-map handling. Done means events use structured exceptions, resolved source locations, preserved cause chains, and a culprit tag in both builds.

Written by the indexing model from the issue text.