exec steps label any unexpected exit code error_class=network

[mlieberman85]

When an exec step's command exits with a code outside pass_exit_codes / fail_exit_codes, _classify_exec_failure (packages/darnit/src/darnit/sieve/builtin_handlers.py) labels the result error_class=network, whatever actually went wrong.

Examples seen in test runs (#548), where nothing touched the network:

• grep exits 2 because .github/workflows/ doesn't exist (OSPS-BR-01.02).
• git exits 128 (no repository, or a missing remote).
• A command exits non-zero because a tool isn't authenticated.

Reports and the stderr summary then tell operators to check their network for what is a local condition. error.class is part of the result contract (feature 041), and operators act on it.

Proposal: classify from the evidence that's available, and default to a neutral class.

• Exit 127, or the executable not found: missing_tool (already defined).
• Known auth messages on stderr: auth.
• Recognizable connection errors on stderr (DNS, connection refused, TLS): network.
• Anything else: a neutral class such as unexpected_exit, carrying the exit code and a stderr excerpt as the cause.

A new class name is a contract change, so it needs a framework-design entry first. grep exiting 2 on a missing directory could also be handled per step, e.g. by the step treating a missing directory as "no workflows" evidence.

(Drafted with Claude Code.)