docs(dogfooding): correct D3 deploy --program-path --json field contract

The D3 scenario claimed the JSON object carries a `tx` field, but the
implementation (src/commands/deploy.rs) intentionally emits `status` and
`program` always, `program_id` when computable from the ELF, and omits
`tx` unless the wallet/RPC exposes an inclusion receipt — which the pinned
LEZ does not. Absent fields are omitted, not nulled, and consumers are meant
to test `has("tx")` / `has("program_id")`. Verified during an end-to-end
dogfooding run: the observed output was
{"program":"hello_world","program_id":"<hex>","status":"submitted"}.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WdK2C8J1YyTkvKzjPuU29Z

DOGFOODING.md

@@ -346,7 +346,7 @@ Use a known default-template program name such as `hello_world`. If the generate
 ### Expected Success Signals
 
 - `deploy hello_world` reports `OK  hello_world submitted` and ends with a human-readable success summary.
-- `deploy --program-path ... --json` prints a parseable JSON object with at least `status`, `program`, and `tx` fields.
+- `deploy --program-path ... --json` prints a parseable JSON object that always carries `status` and `program`, plus `program_id` when it can be computed locally from the ELF. `tx` is present only when the wallet/RPC exposes an inclusion receipt; the pinned LEZ does not, so absent fields are omitted (not nulled) and consumers should test `has("tx")` / `has("program_id")` rather than assume both. Example: `{"program":"hello_world","program_id":"<hex>","status":"submitted"}`.
 - `deploy --program-path ...` without `--json` prints a human-readable `OK` line with the binary path.
 - `deploy nonexistent_program` fails with an error listing the available discovered programs.