Decide: give SOCKET_FORCE per-command names so forcing a self-update doesn't also force apply and vendor

[mikolalysenko]

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

Kind: decision. Source: §1 #6; R9/R10. Register rows C05 and the SOCKET_FORCE part of C35.

Question

One environment variable, SOCKET_FORCE, sets three --force flags whose meanings are unrelated. Should each command get its own variable, and what happens to SOCKET_FORCE?

Options:

1. Split now (recommended). apply keeps SOCKET_FORCE, since bypassing the beforeHash check is the original meaning. --update --force reads a new SOCKET_UPDATE_FORCE. vendor --force reads a new SOCKET_VENDOR_FORCE. Setting SOCKET_FORCE while running --update or vendor prints a one-time deprecation warning for one release, and is then ignored there.
2. Split with no fallback. Same names as option 1, but SOCKET_FORCE stops affecting --update and vendor immediately. This is a breaking change for anyone who scripted SOCKET_FORCE=1 socket-patch --update.
3. Keep as is, and document the coupling as intentional. No code change.

Problem

Three flags are bound to the same variable:

• commands/apply.rs#L333-L343: "Skip pre-application hash verification (apply even if package version differs)."
• commands/vendor.rs#L72-L84: tolerate missing patch-target files and bypass the variant probe.
• commands/update.rs#L54-L64: reinstall or downgrade, and proceed past the managed-install refusal.

CLI_CONTRACT.md documents the sharing (#L973). The env-binding test enumerates all three (args.rs#L1563-L1565).

Environment variables persist across steps, which is how CI and .envrc files use them. A pipeline that exports SOCKET_FORCE=1 to get past a managed-install refusal for a self-update therefore also runs every later apply with hash verification off, and every vendor with missing-file tolerance on. The variable's name doesn't say which commands it affects.

Impact

A safety check is silently disabled by a setting meant for a different command. The change is small once decided.

Proposed change (option 1)

• Rebind update.rs to SOCKET_UPDATE_FORCE and vendor.rs to SOCKET_VENDOR_FORCE. Add both to LOCAL_ARG_ENV_VARS.
• For one release, if SOCKET_FORCE is set and the new variable isn't, honor it with a deprecation warning. A follow-up issue removes the fallback.
• Update the CLI_CONTRACT.md flag tables (lines 87, 89, 891, 973) and the bool-binding test table.

Size and scope

args.rs, commands/{apply,vendor,update}.rs and CLI_CONTRACT.md: about 40 production lines, plus tests. Out of scope: the wider flag cleanup in C34/C35 (deprecated spellings, embedded --vex).

Acceptance criteria

• An owner picks an option on this issue.
• For option 1 or 2: SOCKET_FORCE=1 socket-patch apply still forces. SOCKET_FORCE=1 socket-patch --update warns (option 1) or doesn't force (option 2). SOCKET_UPDATE_FORCE=1 forces only the update.
• every_env_bound_bool_flag_parses_boolishly_and_tolerates_empty covers the new variables.
• The contract's env-var table lists one command per force variable.

Dependencies

None.