An unparseable .socket/manifest.json is reported under five different --json error codes depending on the command #931

[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: register comment.

Kind: bug. Source: new finding, register row C52; child 1 of #930 (C13).

Problem

read_manifest reports malformed JSON or a schema violation as io::ErrorKind::InvalidData, and anything else as a plain I/O error. The contract's top-level code table names manifest_invalid for "exists but is unparseable" and manifest_unreadable for an I/O error. Only list and remove implement that split, and each has its own copy of it (list.rs, remove.rs). Every other command picks its own code for the same Err:

So apply and apply --check disagree with each other, and so do vendor and vendor --check. A CI wrapper that routes on error.code needs five spellings to recognize one corrupt file.

Proof by execution (debug build on 9c43dfc, run twice with identical results). In a project holding package.json and .socket/manifest.json = {"patches": {, each command ran with --json under env -i:

list                    exit=1 code=manifest_invalid
remove pkg:npm/x@1.0.0  exit=1 code=manifest_invalid
apply --check           exit=1 code=manifest_unreadable
vendor --check          exit=1 code=manifest_unreadable
vex --output o.json     exit=2 code=manifest_unreadable
apply                   exit=1 code=apply_failed
repair --offline        exit=1 code=repair_failed
vendor                  exit=1 code=invalid_manifest
rollback --offline      exit=1 error="Failed to parse manifest JSON: EOF while parsing an object at line 2 column 0"

Symptoms

None filed. Impact: a machine-readable contract that differs by command for one condition, and one undocumented code. The change is small.

Proposed change

• Add one mapping next to read_manifest in core (for example manifest_load_error_code(&io::Error) -> &'static str, which becomes an ErrorCode once Tracking: emit every --json error code from one typed ErrorCode registry checked against the contract tables #930's child 2 lands) that returns manifest_invalid for InvalidData and manifest_unreadable otherwise.
• Call it from list, remove, apply (both paths), vendor (both paths) and repair, so that apply and repair stop wrapping the load error in their generic pipeline code.
• Delete the two hand-written InvalidData splits in list.rs and remove.rs, and the undocumented invalid_manifest literal.
• Contract: add apply, repair and vendor to the Subcommands column of the two rows.

Size and scope

About 6 CLI files and one core helper, roughly 60 changed production lines plus tests. Out of scope:

• vex. The contract documents that vex reports an unparseable manifest as manifest_unreadable with exit 2, so moving it to manifest_invalid is a contract change. Either leave it alone, or change it with the contract row in the same PR if the maintainer agrees.
• rollback's bare-string error, which waits on Decide: one shape for the --json top-level error (scan and get emit both a string and a {code, message} object) #704 (Tracking: emit every --json error code from one typed ErrorCode registry checked against the contract tables #930 child 5).

Acceptance criteria

• With an unparseable manifest, list, remove, apply, apply --check, repair, vendor and vendor --check all report error.code == "manifest_invalid" under --json, and their exit codes are unchanged.
• A manifest that can't be read (for example a directory at .socket/manifest.json) reports manifest_unreadable on the same commands.
• Add a regression test that runs that command matrix against one corrupt fixture.
• invalid_manifest no longer appears in the source.
• The existing list/remove manifest_invalid tests stay green.

Dependencies

None; it can land before #930's child 2. It blocks nothing.