fix(api): warn when endpoint contains "?" to prevent silent shell truncation

[DaveHanns]

Summary

Running apify api with an unquoted endpoint that contains a query string is silently truncated by the shell, so the CLI ends up hitting a different URL than the user intended. This PR detects the tell-tale ? in the endpoint arg and emits a stderr warning pointing at two safe forms.

Reproducer

$ apify api /v2/acts?my=1&limit=100

The shell interprets & as the background operator, so the CLI process only receives /v2/acts?my=1 in argv; limit=100 is discarded. The request returns a much larger response than the caller expected (no limit), and there is no indication that anything was dropped. In practice this pushes users (and agents) to abandon apify api and fall back to raw curl, e.g.:

curl -s -H "Authorization: Bearer $APIFY_TOKEN" "https://api.apify.com/v2/acts?my=1&limit=100" | ...

? on its own can also be expanded by the shell as a glob if a matching filename happens to exist in the current directory.

Fix

The CLI cannot see the missing & (the shell consumed it before execve), but the leftover ? in the endpoint is a strong signal that inline query parameters were being passed. When the endpoint contains ?, print a stderr warning with two concrete fixes:

Warning: The endpoint contains a "?". If the command line was not fully
quoted, the shell may have silently dropped everything after an unquoted "&"
or expanded "?" as a glob. Prefer --params to pass query parameters, e.g.
  apify api /v2/acts -p '{"my":1,"limit":100}'
or quote the whole endpoint:
  apify api '/v2/acts?my=1&limit=100'

The warning is stderr-only and does not change exit code or behavior, so this is fully backward-compatible for callers who already quote correctly. The same guidance is added to the command description so apify api --help teaches it too.

Test plan

• apify api /v2/acts?my=1&limit=100 (unquoted) — stderr warning shown, request still proceeds.
• apify api '/v2/acts?my=1&limit=100' — warning shown (same signal, same guidance), request proceeds correctly.
• apify api /v2/users/me — no warning.
• apify api /v2/acts -p '{"my":1,"limit":100}' — no warning; recommended form.
• pnpm test test/local/commands/api.test.ts — new coverage in describe('inline query-string detection', ...) plus all existing api tests still pass (27/27).
• pnpm run update-docs — docs/reference.md regenerated from the updated description; no stale content.

Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.