hive-forge: name the CI job ci-log actually served

`ci-log --run <n> --job <idx>` accepted any index and exited 0. Past the
run's job count it printed job 0's log, with nothing marking the
substitution. Measured against run 3363 (4 jobs): indices 0-3 gave three
distinct md5s, while 99 and 12345 both returned output byte-identical to
job 0.

Both web log routes clamp an out-of-range index to job 0 and answer 200.
I had claimed nothing in the response distinguishes them -- that was
measured on the body only, and the body was the wrong place to look. The
`Content-Disposition` header names the job the server actually served:

    --job 3   -> filename="ci-doc-pointer lint-8363.log"
    --job 99  -> filename="ci-nix flake check-8360.log"   (job 0's)

So the fix is to report what came back rather than to pre-validate the
index. Establishing the real job count needs two extra API calls on every
indexed read -- `ActionRun` carries no job count, and the only job
endpoints are the per-run listing and a per-job log keyed by internal job
id, not by index. The header costs nothing: it is already in the response
being read.

The provenance line goes to stderr, so it cannot corrupt a piped log;
under `--json` it is a `served` field instead. An out-of-range `--job` is
therefore no longer an error -- it is a read whose true subject is named.

`get_bytes_named` is a sibling of `get_bytes_raw` rather than a signature
change, leaving the attachment and artifact download paths untouched.

Rebased onto main after the two flat-rename PRs landed; the only conflict
was the test module's import list, resolved by keeping both sides. While
reading the surrounding context this commit's own defect surfaced:
`check_status`'s doc comment had been left glued to the head of
`disposition_filename`'s, so one function carried two unrelated
descriptions and the other carried none. No gate can see that -- it is
well-formed rustdoc either way.

hive-forge/src/verbs/ci_log.rs

@@ -172,7 +172,7 @@ fn persisted_logs(client: &Client, repo: &str, args: &Args) -> Result<bool> {
         "/{repo}/actions/runs/{}/jobs/{}/attempt/{}/logs",
         args.run, args.job, args.attempt
     ));
-    let Ok(bytes) = client.get_bytes_raw(&url) else {
+    let Ok((bytes, served)) = client.get_bytes_named(&url) else {
         return Ok(false);
     };
     if bytes.is_empty() {
@@ -184,10 +184,18 @@ fn persisted_logs(client: &Client, repo: &str, args: &Args) -> Result<bool> {
             "run": args.run,
             "job": args.job,
             "source": "persisted",
+            "served": served,
             "log": text,
         }))?;
         return Ok(true);
     }
+    // Which job the server actually served, on stderr so it can't corrupt
+    // a piped log. This route clamps an out-of-range `--job` to job 0 and
+    // answers 200, so without naming the file back there is no way to tell
+    // a substituted log from the one that was asked for.
+    if let Some(name) = &served {
+        eprintln!("hive-forge: run #{} job {} -> {name}", args.run, args.job);
+    }
     print!("{text}");
     if !text.ends_with('\n') {
         println!();
@@ -200,6 +208,11 @@ fn persisted_logs(client: &Client, repo: &str, args: &Args) -> Result<bool> {
 /// Returns an error if the run/job can't be fetched from either source
 /// (network, an unknown run number, or a non-2xx), if a requested `--step`
 /// is out of range, or if both sources yield no log content.
+///
+/// An out-of-range `--job` is **not** an error: the web routes clamp it to
+/// job 0 and answer 200, and establishing the real job count costs an extra
+/// two API calls on every indexed read. [`persisted_logs`] names the job the
+/// server actually served instead, from a header already in the response.
 pub fn run(client: &Client, args: Args) -> Result<()> {
     let repo = client.repo()?;
     let stream_path = format!("/{repo}/actions/runs/{}/jobs/{}", args.run, args.job);