Expand troubleshooting guide to cover HMR and dev server slowness (#3804)

## Summary

Improved the troubleshooting docs to help developers discover why their
*entire* dev environment feels slow when using Electric—not just shape
loading, but HMR and dev server responsiveness too.

**User impact:** Developers experiencing slow HMR or unresponsive dev
servers will now find this section when searching for those symptoms,
understanding that it's the same HTTP/1.1 connection limit issue.

## Root Cause (of the documentation gap)

The existing docs explained the HTTP/1.1 6-connection limit well, but
only in the context of "slow shapes." Developers experiencing slow HMR
often didn't realize the connection: Electric shapes holding open
connections starve the dev server's HMR websocket and asset requests.

## Approach

1. **Broadened the section title** to include the symptoms developers
actually search for:
   - Before: "Slow shapes"
   - After: "Slow shapes / slow HMR / slow dev server"

2. **Added the missing connection** between shapes and dev server
performance:
   ```
This also affects your development server (Vite, webpack, etc.) because
the browser's TCP connection limit is shared across all requests to your
   dev server — including HMR updates, asset loading, and shape sync.
   ```

## Key Invariants

- The solution (Caddy with HTTP/2) remains the same—just improving
discoverability
- No changes to the actual technical recommendation

## Non-goals

- Not adding new solutions or workarounds
- Not restructuring the troubleshooting guide

## Trade-offs

**Alternative considered:** Create a separate section for HMR issues.
Rejected because:
- It's the same root cause and same solution
- Would create redundant documentation
- Better to have one authoritative section that covers all
manifestations

## Verification

```bash
pnpm --filter @electric-sql/docs dev
# Navigate to /docs/guides/troubleshooting
# Verify the section now mentions HMR and dev server in the title and body
```

## Files Changed

| File | Change |
|------|--------|
| `website/docs/guides/troubleshooting.md` | Expanded title and added
paragraph explaining how HTTP/1.1 limits affect HMR/dev server |

Co-authored-by: Claude <noreply@anthropic.com>

Author: KyleAMathews

website/docs/guides/troubleshooting.md

@@ -15,12 +15,14 @@ Tips and answers to FAQs about how to run Electric successfully.
 
 ## Local development
 
-### Slow shapes — why are my shapes slow in the browser in local development?
+### Slow shapes / slow HMR / slow dev server — why is my local development slow?
 
-Sometimes people encounter a mysterious slow-down with Electric in local development, when your web app is subscribed to 6 or more shapes. This slow-down is caused by a limitation of the legacy version of HTTP, 1.1.
+Sometimes people encounter mysterious slow-downs with Electric in local development — slow shape loading, sluggish HMR (Hot Module Replacement), or an unresponsive development server. This commonly happens when your web app is subscribed to 6 or more shapes. The slow-down is caused by a limitation of the legacy version of HTTP, 1.1.
 
 With HTTP/1.1, browsers only allow 6 simultaneous requests to a specific backend. This is because each HTTP/1.1 request uses its own expensive TCP connection. As shapes are loaded over HTTP, this means only 6 shapes can be getting updates with HTTP/1.1 due to this browser restriction. All other requests pause until there's an opening.
 
+This also affects your development server (Vite, webpack, etc.) because the browser's TCP connection limit is shared across all requests to your dev server — including HMR updates, asset loading, and shape sync. If Electric shapes are holding connections open, your HMR may take minutes instead of milliseconds.
+
 Luckily, HTTP/2, introduced in 2015, fixes this problem by _multiplexing_ each request to a server over the same TCP connection. This allows essentially unlimited connections. HTTP/2 is standard across the vast majority of hosts now. Unfortunately it's not yet standard in local dev environments.
 
 ##### Solution — run Caddy