Exercise 1: Client-Side Filtering in ParentPicker — Possible Solution
====================================================================

HOW THE FILTER WORKS
------------------------------
Per this chapter, ParentPicker receives the full pages array as a prop
(already fetched once, server-side, before the component renders) and
keeps the search text in local state via useState. Every keystroke
updates query, which triggers a re-render; the filtered array is
recomputed on each render via pages.filter(), comparing each page's own
lowercased fullPath against the lowercased query text.

WHY NO NEW SERVER REQUEST HAPPENS
------------------------------
The entire pages array was already loaded into the browser once, when
the component first received it as a prop. Every subsequent keystroke
only re-filters that same, already-present array in memory - there is
no fetch(), no Server Action call, no network request triggered by
typing at all. This is possible specifically because 'use client' marks
this component to run in the browser, with real interactive state.

CONFIRMATION
------------------------------
Typing "prog" into the search input immediately narrows the displayed
list to only pages whose own fullPath contains that substring (e.g.
"programming", "programming/python") - and opening the browser's own
network tab while typing shows zero new requests firing, confirming the
filtering is genuinely happening client-side.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the full page list was already loaded before
any typing began, correctly identifies useState/filter() as the
mechanism producing the narrowed list on every render, and verifies the
"no per-keystroke request" claim by actually checking network activity
rather than assuming it.