CLI_CONTRACT.md documents status paidRequired for get and scan, but get emits "paid_required" and scan never reports it #982

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

Kind: bug (contract drift). Source: new finding; register C54.

Problem (main @ 9c43dfc)

CLI_CONTRACT.md documents a paid-plan refusal that no command emits, and doesn't document the one that get does emit.

• What the contract says. The envelope's status enum lists "paidRequired". The errorCode table row paid_required says: action failed, status=paidRequired, emitted by "get/scan".

• What get emits. Both paid paths hand-write a legacy object with a snake_case status and no events or errorCode:

  • package/CVE search where nothing is accessible: get.rs#L2894-L2905;
  • get <uuid> on the public proxy (paid view or proxy 403): report_paid_required_uuid.

  Both print {"status":"paid_required","found":N,"downloaded":0,"applied":0,"patches":[…]} and exit 0.

• What scan emits. Nothing paid-specific. It drops inaccessible patches in select_accessible and reports them only as the paidPatches / canAccessPaidPatches counts.``

• Status::PaidRequired is never constructed. The variant is referenced only by tests below #[cfg(test)] (L481). Its own doc comment already says "Nothing emits it yet (get reports this via its legacy status: "paid_required" shape; scan never does)". So the code knows; the contract was never updated.

Proof by execution. On 9c43dfc, cargo test -p socket-patch-cli --test get paid ran twice: 4 passed both times. Those tests pin status == "paid_required" and exit 0 for both get paths: get_edge_cases_e2e.rs#L241-L287 and get_invariants.rs#L439-L490.`` A consumer that follows the contract and matches status == "paidRequired" or `errorCode == "paid_required"` never matches.

Symptoms

None filed. PR bots that implement the documented "upgrade your plan" branch silently never take it.

Impact

Small and user-visible: the documented machine contract for the paid tier is wrong in three ways (status spelling, action/errorCode, and the command list). It's another instance of C13/C33: the contract's code tables aren't checked against the code.

Proposed change

Make the contract describe what ships. No behavior change.

• Rewrite the paid_required row (L1163): get only; legacy top-level status: "paid_required" with found/downloaded/applied/patches[], exit 0, no events/errorCode. Keep the existing get <uuid> proxy sentence, which is accurate.
• State that scan reports paid patches only through paidPatches and canAccessPaidPatches.
• In the status enum (L1092), mark paidRequired as reserved, or remove it. Deleting Status::PaidRequired and its two test references is optional and belongs with this change if it is removed.
• Route the two hand-written get JSON blocks through one helper so the shape is written once.

Moving get onto the unified envelope (where paidRequired would become real) is the owner decision in #704 and is out of scope here.

Size and scope

CLI_CONTRACT.md (two lines), get.rs (one shared ~20-line emitter replacing two blocks), and optionally json_envelope.rs (−6 lines). Under 60 changed lines.

Acceptance criteria

• The contract's paid_required row and status enum match the emitted JSON.
• get's two paid JSON blocks share one emitter.
• The 4 --test get paid tests stay green.
• Add a test that reads the contract's paid_required row and asserts the status spelling get emits, in the style of contract_gradle_codes.rs.

Dependencies

• Independent of Decide: one shape for the --json top-level error (scan and get emit both a string and a {code, message} object) #704; if Decide: one shape for the --json top-level error (scan and get emit both a string and a {code, message} object) #704 later moves get onto the envelope, that PR updates this row again.
• Feeds Tracking: make CLI_CONTRACT.md a checked reference plus short prose #948 (checked contract reference) and Tracking: emit every --json error code from one typed ErrorCode registry checked against the contract tables #930 (typed error codes).