run_pipeline: Command._run_stage_c and Command._run_stage_d_bulk are unreachable after #666

[WilfordGrimley]

Problem

Issue #666 ("Streaming pipeline default: micro-batch Stage C/D dispatch and verdict transfer")
made the streaming conveyor the default path. Two methods of the previous batch path survived the
change and are now unreachable: | Symbol | Location | Size |
|---|---|---|
| Command._run_stage_c | MPCAutofill/cardpicker/management/commands/run_pipeline.py:544-585 | ~42 lines |
| Command._run_stage_d_bulk | MPCAutofill/cardpicker/management/commands/run_pipeline.py:586-644 | ~59 lines |

handle() now branches only on --skip-stage-c, and in every case dispatches to
self._run_streaming_stages(...) (line 645). Neither dead method has a single self. call site
anywhere in the file, and no test calls them: the only _run_stage_c reference in
tests/test_run_pipeline.py is monkeypatch.setattr(stage_e_dispatch, "_run_stage_c", _stub_stage_c)
at line 232, which patches a different symbol entirely.

The reason this was not obvious

Command._run_stage_c shares its name with stage_e_dispatch._run_stage_c, which is very much
alive — 54 references across 19 files. A grep for _run_stage_c reports the name as heavily used,
so any grep-based dead-code sweep concludes the method is live. It is a name that lies, and it is
the kind of thing the self-reference audit's "names and docs that lie" hole is about.

(Note for anyone re-deriving the counts: .claude/worktrees/agent-three-fixes/ and
.claude/worktrees/agent-ci-red/ hold stale copies of this file and must be excluded.)

Ask

Delete both methods, or — if either is intended as a supported non-streaming escape hatch —
wire it back to a real flag and give it a test. Deciding which is part of the issue.

Acceptance

• run_pipeline.py contains no method unreachable from handle()
• full backend suite still green
• if anything is kept, it is reachable by a documented flag and covered by a test that fails when
  the path breaks