fix(dispatch): close result-pull gaps left by the first pass

[bobleer]

Four loose ends in the result-return path shipped in #1893. None were reported as failures — they came out of re-reading that change.

An older target failed with clap's own error

workspace_result_bundle is advertised and deliberately kept out of REQUIRED_DISPATCH_CAPABILITIES, so a CLI predating it stays fully usable for running jobs. But nothing ever checked it, so pulling from such a target surfaced:

unrecognized subcommand '__workspace_result'

which tells the user nothing about what to do. The pull now probes for the capability first and fails with the actual remedy. Checked against the live protocol rather than anything cached, so it cannot go stale.

The staging directory did not follow its own neighbour's rule

Result bundles land beside .workspace-uploads, which hardens itself to 0700 even though the outbound root is already owner-only. .results was created with a bare create_dir_all, and its bundle and summary written under the process umask.

To be precise about severity: the parent's 0700 does block traversal today, so this was defence in depth rather than an open door. But the bundle carries the user's source — including the ignored files the snapshot deliberately shipped — and the summary beside it records which paths changed. Both are now created 0600 before writing, so their contents are never briefly umask-governed, and the directory is hardened like its neighbour.

Pulled bundles were never collected

remove_workspace_snapshot clears only .workspace-uploads. Terminal jobs expired after 30 days while their bundles accumulated indefinitely.

remove_result_bundle is called from the same retention sweep. Kept separate from the snapshot removal on purpose: that one runs as soon as the target durably owns the job, which is long before the user has had a chance to look at the results.

Account devices could receive a snapshot but never return one

Device dispatch has a full chunked upload path, yet pull_result bailed with requires an SSH target — so a device-dispatched snapshot job had no way home.

SSH pulls the bundle over SFTP; a device transport carries JSON only. So there is now a bounded read-side verb that streams the same bytes back in base64 chunks, mirroring the upload. It never rebuilds the bundle, so the digest the target reported stays the digest the controller verifies, and the reassembled bytes are checked against it before anything is staged. Both transports record the same durable summary, so the apply step stays transport-blind.

Verification

Through the real CLI:

Check	Result
Chunked read across five 64-byte chunks	reassembled, digest matches
offset == size	returns eof with an empty tail
offset > size	rejected
length = 0	rejected
length beyond the cap	rejected
New verbs in dispatch --help	hidden, as with the other data-plane verbs

Device streaming and its digest-mismatch refusal are covered by tests over a stub RPC, including a multi-chunk bundle to exercise the loop rather than a single-shot read.

Automated: 122 services-integrations, 100 services-core, 15 dispatch controller/store, 54 CLI.

Out of scope, flagged not fixed

cargo clippy --all-targets on services-integrations reports three deny-level octal_escapes errors at manager.rs:6037. They are pre-existing on main, unrelated to this change, and only --all-targets surfaces them (the literal is in a #[cfg(test)] module), which is why the Rust Build Check stays green. Left alone rather than mixed into this PR.