tech-debt(apiclient): regenerate log-search client; remove hand-marshalled bypass

[tkkhq]

Context

Follow-up debt surfaced while reviewing the (now-closed) PR #19 "fix(logs): use project log search selectors".

That change moved function/frontend runtime + build log reads onto POST /projects/{id}/logs/search with the server's new nested resource selector ({type, ids, deployments:{ids}}).

Problem

The generated apiclient is stale: the typed body SearchProjectLogsJSONRequestBody (= common.LogSearchRequest) still carries the old flat shape (resource_type / resource_ids / bucket_count …) with no nested resource object.

To work around this, PR #19 hand-marshals a local logSearchRequest struct (internal/api/logs.go) and calls SearchProjectLogsWithBodyWithResponse instead of the typed SearchProjectLogsWithResponse. The same pattern was applied to GetProjectLogActivity (its apiclient test was rewritten to ...WithBody + a raw JSON literal).

This works today, but leaves a trap: any future caller using the typed SearchProjectLogsWithResponse will silently send the wrong wire format.

Proposed fix

• Regenerate internal/apiclient from the updated OpenAPI spec so LogSearchRequest / log-activity bodies match the nested resource shape.
• Drop the hand-marshalled logSearchRequest types in internal/api/logs.go and switch back to the typed SearchProjectLogs*WithResponse calls.
• If the spec update is blocked, add a comment in internal/api/logs.go explaining why the typed body is intentionally bypassed, so it isn't "fixed" back to the broken typed call.

Smaller related cleanup

• Tests in internal/api/client_test.go and internal/api/frontends_test.go route runtime-vs-build /logs/search responses by call order (len(logSearchBodies)==1) rather than by request content. Branch on the body (e.g. resource.deployments != nil → build) to make them robust, matching the approach already used in the command-level tests.

Refs: PR #19, HOSTING-452.