[AI] docs(sync): cross-link troubleshooting sections to shape-handle deletion taxonomy (#4750)

## Summary

[PR #4097](#4097) (merged
2026-08-03) added a "Why shape handles get deleted" taxonomy in
[website/docs/sync/guides/shapes.md](https://github.com/electric-sql/electric/blob/main/website/docs/sync/guides/shapes.md#why-shape-handles-get-deleted).
Users hitting `409` responses in the troubleshooting guide benefit from
a direct path to that taxonomy.

This PR adds two reciprocal cross-links in
[website/docs/sync/guides/troubleshooting.md](https://github.com/electric-sql/electric/blob/main/website/docs/sync/guides/troubleshooting.md):

1. End of the "Unexpected 409 — why is my shape handle invalid?"
section: points to the full taxonomy (replication slot, schema,
eviction, explicit API, client-side behavior).
2. End of the "Replication slot recreation — why are all clients
resyncing after a crash?" section: points to the broader taxonomy
(replication slot or timeline, schema, eviction, explicit API).

Docs-only change, no behavior modification, no schema change. Follows up
on @alco's 2026-08-03 invitation on [issue
#2680](#2680)
("@dikshit-n I have merged @fru1tworld's PR. Feel free to suggest
further improvements if you have any").

## Changes

- `website/docs/sync/guides/troubleshooting.md`: +4 lines, -0 lines
  - +1 link after L170 ("Unexpected 409" section)
  - +1 link after L416 ("Replication slot recreation" section)

## Testing

- Verified the anchor `why-shape-handles-get-deleted` resolves to the
new section in `shapes.md` (VitePress auto-generates anchors from
heading text).
- No code paths affected; docs-only.
- The cross-links use the same
`/docs/sync/guides/shapes#why-shape-handles-get-deleted` path style as
the existing `See the troubleshooting guide` link in PR #4097, so the
link shape is consistent with the new section's outbound references.

## AI Usage Disclosure

The initial implementation was drafted with Claude and then reviewed,
edited, and tested by me.

## Checklist

- [x] Docs only — no code, no schema, no behavior change
- [x] No new dependencies
- [x] No release-notes / changeset required (this matches the pattern of
recently merged docs PRs #4097, #4740, #4739)
- [x] Self-review done
- [x] PR is opened from a fresh branch off `main`; rebase-friendly (no
merge commits)

## Related

- Closes (does not close, no linked issue — follow-up to @alco's
invitation on #2680):
[#2680](#2680)
- Builds on: [#4097](#4097)
(merged 2026-08-03)

<!-- codesmith:footer -->
---
<a
href="https://app.blacksmith.sh/electric-sql/codesmith/electric/pr/4750"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v2.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-light-v2.svg"><img
alt="View with [code]smith"
src="https://pr-comments-assets.blacksmith.sh/codesmith/view-with-codesmith-dark-v2.svg"></picture></a>
<a
href="https://backend.blacksmith.sh/track/enable-autofix?expires=1788403505&installation_model_id=8736&pr_number=4750&repository=electric-sql%2Felectric&return_to=https%3A%2F%2Fgithub.com%2Felectric-sql%2Felectric%2Fpull%2F4750&signature=8e662a0860742a2b7f302618f4966831f80715a8779f0960c6b1cb6becf6e245"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-light.svg"><img
alt="Autofix with [code]smith"
src="https://pr-comments-assets.blacksmith.sh/codesmith/autofix-with-codesmith-dark.svg"></picture></a>
<sup>Need help on this PR? Tag <code>@codesmith-bot</code> with what you
need. Autofix is disabled.</sup>

<!-- codesmith:autofix:disabled -->
<!-- /codesmith:footer -->

Author: dikshit-n

website/docs/sync/guides/troubleshooting.md

@@ -169,6 +169,8 @@ This indicates that your client library or proxy layer is caching requests to El
 
 The problem will resolve itself as client/proxy caches empty. You can force this by clearing your client or proxy cache. See [Control messages](/docs/sync/api/http#control-messages) for more context on 409 messages.
 
+For a full taxonomy of why shape handles get deleted (replication slot changes, schema changes, shape eviction, explicit API deletion, client-side behavior) see [Why shape handles get deleted](/docs/sync/guides/shapes#why-shape-handles-get-deleted) in the Shapes guide.
+
 ## Production
 
 ### 503 — concurrent request limit exceeded
@@ -415,6 +417,8 @@ This means all existing shapes are invalidated. Clients will receive `409` (must
 - Monitor your replication slot health with the [diagnostic checklist](#quick-diagnostic-checklist) above
 - Set `max_slot_wal_keep_size` conservatively to avoid unexpected slot invalidation
 
+For the broader taxonomy of shape-handle deletion causes (replication slot or timeline changes, schema changes, shape eviction, explicit API deletion) see [Why shape handles get deleted](/docs/sync/guides/shapes#why-shape-handles-get-deleted) in the Shapes guide.
+
 ### Rolling upgrades — why is my second instance stuck in 'waiting' state?
 
 This is expected behavior during a [rolling upgrade](/docs/sync/guides/upgrading). The second instance has loaded shape metadata and is serving existing shapes in read-only mode while waiting for the first instance to release the advisory lock. Check `/v1/health` to confirm — a `202` response with `{"status": "waiting"}` indicates the instance is healthy and serving reads.