fix(use-fetch): default queryString in useFetchCol

[MaxAdams98]

The bug

useFetchResource interpolates queryString straight into the url:

const response = await request(`get /api${endpoint}${queryString}`)

useFetchCol passes it through undefined, so a call that omits it requests /api/<endpoint>undefined:

useFetchCol<OptionList>('/option-lists')   // -> GET /api/option-listsundefined

useFetchDoc, three lines above, already guards it:

export function useFetchDoc<T>(endpoint?: string, queryString?: string) {
  return useFetchResource<T>(endpoint, queryString || '', true) as DocumentReturn<T>
}

So the two siblings behave differently for the same omitted argument, which reads like an oversight rather than a decision.

The fix

One line, making useFetchCol match useFetchDoc.

How it turned up

Three admin screens in a project on 0.3.13 rendered empty with no error after adopting the shared hooks. The router logs showed the requests going to /api/option-listsundefined. Nothing catches it locally: undefined is valid for an optional string, so typecheck passes, and the request returns a response rather than throwing.

Calls that pass location.search are unaffected, which is why it looks isolated at first.

🤖 Generated with Claude Code