ntk push exits successfully after an upload fails

[next-devin]

What happens now

If an upload fails during ntk push, ntk prints the API error and stops uploading files.

The command still exits with status 0. Shell scripts, CI jobs, and agents therefore treat the push as successful.

How to reproduce

1. Run ntk push with at least two files and an invalid or expired API key.
2. The first upload fails.
3. The second file is not attempted.
4. Run echo $?.

The exit status is 0 even though the push failed.

The same behavior can be reproduced in a test by returning a failed response for the first file. Only one upload is attempted, and the command finishes normally.

What should happen

Keep the current stop-on-first-failure behavior for now.

When an upload fails, ntk should:

• stop the push;
• print the name of the failed file;
• print how many files were uploaded and how many were not attempted;
• exit with a non-zero status.

If every file uploads successfully, the command should exit with status 0.

Whether ntk should continue after some types of file error is a separate decision. This issue does not change pull or watch.

Done when

• A failed upload causes ntk push to exit with a non-zero status.
• The output names the failed file and reports how much work was completed.
• Files after the failed upload are not attempted.
• A successful push still exits with status 0.
• Tests cover successful and failed pushes.

[next-devin]

@alexphelps requesting your blessing on the approach before anyone opens a PR here — platform owns this CLI, so nothing proceeds without your sign-off.

Proposed behavior changes, smallest useful set:

1. Non-zero exit codes. Any command that hits an API failure exits non-zero (today __main__.py never calls sys.exit with a code, so agents and scripts cannot detect failure). Success paths unchanged.
2. Per-file push/pull summary. push/pull currently stop silently at the first failed file (command.py:89-90). Proposal: continue through the list, then print a summary naming successes and failures, and exit non-zero if any failed.
3. Bounded 429 retry. gateway.py:18-19 retries throttled responses in unbounded recursion with no delay. Proposal: capped retries with backoff, then a clear terminal error. (This is the same territory as the old rate-limit PRs 20 improve rate limit handling #21/20 improve rate limit handling #22.)

Compatibility note: the only observable change for existing scripts is that failures start returning non-zero, which is the point. If you want any of this behind a flag instead, or want it shaped differently, say the word — we'll build to whatever you bless.

[alexphelps]

@next-devin

Non-zero exit codes. Any command that hits an API failure exits non-zero (today main.py never calls sys.exit with a code, so agents and scripts cannot detect failure). Success paths unchanged.

How to reproduce to see what we are fixing?

Per-file push/pull summary. push/pull currently stop silently at the first failed file (command.py:89-90). Proposal: continue through the list, then print a summary naming successes and failures, and exit non-zero if any failed.

How to reproduce to see what we're fixing?

Bounded 429 retry. gateway.py:18-19 retries throttled responses in unbounded recursion with no delay. Proposal: capped retries with backoff, then a clear terminal error. (This is the same territory as the old rate-limit PRs #21.)

I see no benefit in exponential backoff on the theme context, what is the problem here? Are you hitting rate limits?