enhancement: give moon_cli.py meaningful exit codes for scripting

[LeyckerS]

Context

moon_cli.py exists so MoonDownloader can run unattended — cron, a scheduled task, a step in a larger script. That only works if the caller can tell success from failure without parsing the log.

Today the CLI does not distinguish outcomes in its exit status, so a run where 3 of 29 files failed looks identical to a clean run from the outside.

What to do

Define and implement three exit codes in moon_cli.py:

Code	Meaning
0	every file in the batch completed
1	the run completed but at least one file failed (dead link, exhausted retries, extraction failure)
2	the run could not start — bad arguments, unreadable link file, invalid configuration

Rules:

• A partial failure is still exit 1, not an exception. The remaining files must still be attempted; the code reports the outcome, it does not abort the batch.
• Exit 2 is pre-flight only. Once the first download starts, the outcome is 0 or 1.
• Keep the existing summary line on stdout unchanged — scripts may already be grepping it.

Acceptance criteria

• A batch where every file succeeds exits 0
• A batch containing one guaranteed-dead link exits 1, and the surviving files still download
• An unreadable link file exits 2 before any network activity
• A test in tests/ covers all three, with the network stubbed the way test_no_chrome.py already does
• The table above is documented in docs/CLI.md

Depends on

#28 creates docs/CLI.md. If that page does not exist yet when you open the PR, add the exit-code table to your PR and note it — the two will be reconciled on merge.

Notes for the contributor

This one touches real behaviour rather than docs or config, so read moon_cli.py end to end first. CONTRIBUTING.md has the rules that are not style preferences — in particular, moon_cli.py currently carries its own copy of the download engine, so check whether your change needs to land in moon_engine.py too.

Comment here before you start.

[LeyckerS]

Note for whoever takes this — the current behaviour is narrower than "always returns 0", and knowing where the gap actually is will save you reading the whole file.

moon_cli.py does exit non-zero in three places, all of them before or around the run rather than about its outcome:

• moon_cli.py:319 — URL file not found
• moon_cli.py:325 — file parsed but no URLs in it
• moon_cli.py:342 — an unexpected top-level exception, after writing crash_log.txt

What is missing is the outcome itself. After asyncio.run(...) returns, main() falls off the end, so a run that completed exits 0 whether one file failed or every file did. KeyboardInterrupt is caught at moon_cli.py:335, prints Interrupted. and also exits 0 — worth deciding on deliberately rather than by omission, since a cancelled run is not a successful one.

So the work is mostly: get the failure count out of the run and choose the codes. The engine already tracks it; download_file failures land in the failed-URL list that failed_links.txt is written from, which is the number you want.

Distinct codes for "some failed" and "all failed" are worth having, but pick whatever scheme you can defend and say so in the PR — I care more that it is documented in docs/CLI.md than which numbers you choose.

[LeyckerS]

Claimed by @AdvaitVarhade — #153 is open against this issue.

GitHub will not let me set the assignee field: it only accepts collaborators, or people who have commented on this issue specifically, and a comment on the pull request does not count. So this note is the claim record. @AdvaitVarhade, if you drop any comment here I can set the field properly and it will show in the listings.