Suggestion succession rows grow without the 2,000-entry cap although the app never reads them

## Problem

Every finished value with a predecessor creates or increments a `succession` row. Entry eviction deletes only `entry` rows; succession rows reference the surface, not either entry. Consequently the per-surface entry cap does not bound disk use or the history of predecessor/successor strings. The shipping capture path supplies predecessors even though the app never invokes `successors()`.

## Evidence

Reviewed `main` at `8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d`. Reproduced against the unchanged production source in an isolated Swift package on macOS, with fake transport or temporary stores as appropriate. These checks assert the observed defect; they are not a claim that the full app test suite passed.

Record 2,100 distinct lines in one surface, each with a distinct `after:` value, using the production store and a temporary SQLite file. Observed:

```text
entry rows: 2000
succession rows: 2100
```

The extra rows survive normal entry eviction. Repeating with more distinct pairs has no cleanup path until the whole surface is forgotten. This is row-count evidence, not a measured end-user latency claim.

## Relevant code

- [Sources/UttrflowPredictStore/PredictStore.swift:262](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredictStore/PredictStore.swift#L262)
- [Sources/UttrflowPredictStore/PredictStore.swift:400](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredictStore/PredictStore.swift#L400)
- [Sources/UttrflowPredictStore/Schema.swift:46](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredictStore/Schema.swift#L46)
- [Sources/UttrflowPredictCapture/CaptureSession.swift:125](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredictCapture/CaptureSession.swift#L125)

## Fix and acceptance criteria

If succession is not used, stop maintaining it and provide a migration to remove obsolete rows; otherwise define and enforce a bound tied to retained entries or age. Add an eviction test that checks all tables, not only `entryCount()`.

## Existing work checked

#647 identifies the unused successors API. This issue is the separate active write/storage consequence: capture still grows the succession table on ordinary usage.

Read the succession and eviction paths in Sources/UttrflowPredictStore/PredictStore.swift, the schema in Sources/UttrflowPredictStore/Schema.swift, and capture writes in Sources/UttrflowPredictCapture/CaptureSession.swift. Reproduce the 2,100-line scenario with a temporary SQLite store, then add an eviction test that checks every table. Done means obsolete succession data no longer grows beyond the retained-entry policy and migration or cleanup behavior is covered.

Written by the indexing model from the issue text.