perf(storage): SQL history index + prune without nested OFFSET delete

[ZhuchkaTriplesix]

Parent

Part of #414

Problem

History prune uses nested DELETE … SELECT … ORDER BY … OFFSET. Index is (connection_id, recorded_at DESC) but predicates use database_name IS NOT DISTINCT FROM ?, so prune can scan more rows than needed as history grows across DB buckets.

Evidence

• lib/core/storage/local_db.dart (schema indexes + history prune)

Acceptance

• Index supports (connection_id, database_name, recorded_at DESC) (or equivalent)
• Prune deletes by primary key / simpler plan (no nested OFFSET scan when avoidable)
• Migration covered; existing DBs upgrade cleanly

Suggested fix

Add composite index; count then delete by id; keep per-connection/database caps.

[ZhuchkaTriplesix]

Shipped on dev via #442 (Closes did not auto-close because PRs targeted dev).