docs: remove resolved plan

plans/005-limit-home-continue-watching-carousel-query.md

@@ -1,35 +0,0 @@
----
-finding: "Limit home continue-watching carousel query"
-catalog: "Performance"
-impact: "A large local library can make the home page fetch and render every continue-watching row for a carousel."
-base_commit: "0d31d46"
----
-
-## Effort
-
-S - add a bounded query and route it through the catalog section path.
-
-## Risk
-
-LOW - the home carousel can be limited without changing full watchlist behavior.
-
-## Confidence
-
-HIGH - the current query is unbounded and the template renders every returned row.
-
-## Evidence
-
-- `templates/index.gohtml:5` loads `/api/catalog/continue` on page load.
-- `internal/anime/service.go:56-60` calls `GetContinueWatchingEntries` for the Continue section.
-- `internal/db/queries.sql:100-118` defines `GetContinueWatchingEntries` without `LIMIT`.
-- `templates/components/continue_watching.gohtml:7-43` ranges over every returned row.
-
-## Resolution Approach
-
-Add a separate limited query for the home-page continue-watching carousel, ordered by `updated_at DESC`. A limit around 20-30 entries is reasonable for a horizontal carousel; choose a named constant in Go rather than scattering a magic number.
-
-Do not change any full watchlist or management views unless they intentionally share this carousel endpoint. Keep the existing unbounded query only if another path truly needs the full set; otherwise rename queries to make their purpose clear.
-
-Update service tests or add repository/service tests that seed more rows than the limit and assert the Continue catalog section returns only the most recent entries in order. If generated SQL files are maintained manually in this repo, update generated query code consistently with existing patterns; if generated by sqlc, use the project’s existing generation workflow only if documented and non-destructive.
-
-Verify with `go test ./internal/anime ./internal/db ./...`.