fix: builds abort, runs --status filter, and dataset command correctness

[Ayush7614]

Summary

• Adds apify builds abort for parity with runs abort (platform build abort already existed via signal handling, but had no dedicated command).
• Adds apify runs ls --status so runs can be filtered by job status (API-supported).
• Fixes real dataset bugs: wrong “Key-value store not found” message and wrong KVS pricing constant in datasets info; corrects misleading rename help text for datasets and key-value stores.
• Expands datasets get-items with --fields, --omit, --unwind, --clean, --desc, and --output, and routes resolution through shared tryToGetDataset.
• Aligns builds log not-found handling with runs log, regenerates docs, and extends e2e/local coverage.

These are independent fixes/features with no claimed open issues.

Test plan

• pnpm run lint
• pnpm run format
• pnpm run build
• pnpm run test:local (377 passed, including new storage-size unit tests)
• e2e suites for builds/runs/datasets with TEST_USER_TOKEN

[l2ysho]

thx @Ayush7614, here are some quick findings

[l2ysho]

These two assertions are mutually exclusive, so this test can't pass.

src/commands/builds/log.ts replaced throw new Error(...) with error({ ... }); return. error() (src/lib/outputs.ts) only logs — the non-zero exit code came from the framework's catch in src/lib/command-framework/apify-command.ts. So apify builds log <bad-id> now exits 0 and line 192 fails.

Which branch is live: apify-client's _get swallows 404 into undefined, so !build is the path taken here — that's confirmed by the untouched, currently-green builds info test above (fails with invalid build ID), which runs identical code. So stdout will match and only the exit-code assertion fails. If .get() did reject instead, line 193 would be the one to fail. Either way the pair can't both hold.

Two ways out:

• drop line 192 and assert stdout only (this is what the new builds abort tests do, correctly), or
• set process.exitCode = 1 before the return in log.ts and keep both.

I'd prefer the second — losing the non-zero exit code on "build not found" is a user-visible regression for anyone scripting this.

[l2ysho]

This swallows log-fetch failures and reports success. Before, an exception from outputJobLog propagated and the command exited 1. Now, if the build exists but client.log(id).get() 5xx's or the log is gone, the user gets Info: Log for build with ID "x": on stdout, Error: Failed to get log… on stderr, and $? == 0.

Concretely: apify builds log $ID > build.log && next-step proceeds with an empty file.

I see this was copied from src/commands/runs/log.ts — but there the swallow is annotated (// This should never happen..., dropped in the copy), and regardless it's a new regression for builds log. Either rethrow, or process.exitCode = 1 in the catch.

Minor inconsistency while you're here: line 35 sends its error to stdout (stdout: true) and line 44 to stderr, in the same command.

[Ayush7614]

@l2ysho thanks for the catch — addressed in the latest commit:

• apify builds log now sets process.exitCode = 1 when the build is not found (so the e2e assertions aren’t mutually exclusive anymore)
• Log-fetch failures in the catch also set a non-zero exit code, with error output aligned to stdout
• Branch is also updated with master