Brief Cursor's Agent mode to build a multi-file feature without wandering into untouched files

You are working in Cursor's Agent mode with multi-file edit access across this repository's indexed codebase. Build the feature below end to end, but treat every boundary in this brief as a hard constraint, not a suggestion you can override if you find a "better" way mid-edit.

FEATURE
Add a "save search" button on the results page that stores the current filters under a name and lists saved searches in the sidebar for the logged-in user.

FILES YOU MAY CREATE OR MODIFY
app/search/results/page.tsx, app/search/results/SavedSearches.tsx (new), lib/searches/store.ts (new), app/api/searches/route.ts (new)

DATA CONTRACT BETWEEN THESE FILES
SavedSearch = { id: string, name: string, filters: FilterState, createdAt: string }. The API route returns SavedSearch[]; the sidebar component takes searches: SavedSearch[] as a prop.

OUT OF SCOPE — DO NOT TOUCH EVEN IF IT LOOKS RELATED
Do not touch the existing filter-parsing logic in lib/search/parseFilters.ts, and do not modify the results table component itself.

CODEBASE CONVENTIONS TO MATCH
API routes return { data, error } tuples, never throw across the route boundary. Shared types live in lib/types/, never inline in a component file. Errors are logged via lib/logger.ts, never console.log.

BEFORE WRITING ANY CODE
List every file you intend to create or modify, in the order you'll edit them, and state which sentence of the feature description each edit satisfies. If that plan requires a file outside FILES YOU MAY CREATE OR MODIFY, stop here and name it explicitly before touching it — do not expand scope silently mid-session just because the codebase index surfaced a plausible "related" file while you were searching for something else.

WHILE EDITING
- Keep the data contract above literal on both ends of every file boundary it crosses. If satisfying the feature actually requires changing a field name or shape, say so and wait for confirmation rather than adapting one side quietly while the other goes stale.
- Do not add a new dependency, even a small one, without naming it and the specific reason it's needed first — a "simpler" implementation using an existing utility is always the default unless one genuinely doesn't exist.
- Match the codebase conventions given above exactly — naming patterns, error-handling style, where types live — rather than defaulting to whatever pattern is most common in your own training data. A new file that's individually well-written but stylistically foreign to everything around it has failed this brief even if it works.
- Do not run a workspace-wide build, lint, or test command when the change only touches a handful of files; use the narrowest scoped command available and say which one you ran.

WHEN DONE
List every file changed, one line each, mapped to the specific requirement it satisfies. Separately, list anything from the feature description you could not finish and exactly why — a missing dependency, an ambiguous requirement, a conflict with an existing pattern — rather than silently shipping a partial implementation dressed up as complete. If you made any judgment call the brief didn't explicitly cover, name it and the reasoning, so it can be checked rather than discovered later.