Extract a reusable hook without changing what the component does

You are a senior React engineer extracting a single piece of stateful logic out of an existing component into a custom hook. This is a mechanical extraction, not a redesign — the component's rendered output and runtime behavior must be identical before and after the change.

COMPONENT
function ProductSearch() { const [query, setQuery] = useState(""); const [results, setResults] = useState([]); useEffect(() => { const id = setTimeout(() => fetch("/api/search?q=" + query).then(r => r.json()).then(setResults), 300); return () => clearTimeout(id); }, [query]); return (/* JSX */); }

LOGIC TO EXTRACT
The debounced search input state and the effect that fires the API call and stores the results.

WHY THIS NEEDS TO BE A HOOK
We just added a second component (TagSearch) that needs the identical debounced-fetch behavior, and copy-pasting the effect a second time is how the two will drift out of sync.

TARGET LANGUAGE
TypeScript, strict mode enabled

HOOK NAMING AND CONTRACT
Name the hook use<Something> based on what it does for the caller, never how it happens to be implemented internally — useDebouncedSearch, not useStateAndEffect. The hook must return a small, explicit object or tuple with named fields; nothing in the calling component should have to reach into an unrelated piece of returned state to make sense of what came back. If the hook needs configuration — a delay, an initial value, a callback — make those explicit parameters with sane defaults, not a hidden module-level constant or a context read the caller can't see or override.

DEPENDENCY-ARRAY DISCIPLINE
Preserve every effect's dependency array exactly as it is today unless you can name the specific stale-closure or missing-dependency bug the current array causes. Extraction is not license to "fix" timing nobody asked you to fix — a dependency array that changes when an effect fires is a behavior change wearing a refactor's clothes.

REUSABILITY HONESTY
If the logic depends on something specific to this one component — a particular prop name, a DOM ref only this component happens to have, a string hardcoded for this one screen — do not silently generalize it into a fake-generic parameter, and do not silently leave it hardcoded either. Leave an explicit TODO comment naming exactly what would need to become a parameter before another component could genuinely reuse this hook.

TYPE SAFETY
If the target language is TypeScript, type the hook's parameters and return value explicitly. No implicit any on the returned object, and no widening a specific union the original code relied on (a status of 'idle' | 'loading' | 'error' | 'success') into a bare string.

OUTPUT FORMAT
1. The new hook, in its own code block, with a one-line comment directly above its signature stating its contract (inputs to outputs).
2. The component's render body, updated to call the hook instead of containing the extracted logic — nothing else about the component should change, including formatting you didn't need to touch.
3. A short note listing anything deliberately left component-specific per the TODO rule, or an explicit statement that nothing was left coupled if that's genuinely true.
4. Any judgment call you had to make where these rules didn't fully cover the case, and why you made it.