docs(readme): document --json as the supported machine-readable output

[MukundaKatta]

Description

Issue #3227 asked for a note in the README that the default human-readable CLI output is not a stable API and that scripts/CI should use `--json` instead. On that thread @samtstern ("the CLI output without --json is not part of our API and you can change it at will") and @bkendall ("Adding some information to the README is always welcome! if you wanted to start a PR with what would be useful to you, we could iterate on that with you") agreed and explicitly invited a PR.

The README currently has no mention of `--json` at all — users coming from issue triage or Stack Overflow land on "Using with CI Systems" and then "Using as a Module" without anything in between pointing them at the supported, parsable surface.

This PR adds a new "Machine-readable output" section between those two, covering:

• Why the default stdout format is not a stable API.
• What `--json` changes about the output (single JSON document on stdout regardless of exit code, stable across versions).
• A worked example pair showing the same `hosting:channel:list` call with and without `--json | jq`.
• A pointer to the existing "Using as a Module" section for callers that need thrown errors instead of exit codes.

Scenarios Tested

• `prettier --check README.md` passes.
• Docs-only change — no runtime behavior or tests affected.
• Scanned the existing README for cross-reference anchors; used `#using-as-a-module` which is the slug the current section renders as.

Sample Commands

No command surface changes. The new section documents existing `--json` behavior that already ships on commands today. The worked example from the docs:

```bash

Human output (default) — do not parse this in scripts

$ firebase hosting:channel:list --project my-project

Machine output — safe to parse in CI

$ firebase hosting:channel:list --project my-project --json | jq '.result.channels[].name'
```

Closes #3227.

[gemini-code-assist]

Code Review

This pull request adds a new 'Machine-readable output' section to the README, documenting the use of the --json flag for scripting and automation. The review feedback suggests explicitly mentioning the top-level status field in the JSON output description and fixing a markdown link that was split across multiple lines to ensure better readability and parser compatibility.

[gemini-code-assist]

It would be beneficial to explicitly mention the top-level status field in the JSON output. This helps users understand how to distinguish between success and error responses programmatically, especially since the example below relies on the .result field.

Suggested change

	- `stdout` receives a single JSON document describing the command's
	result — parsable regardless of exit code.
	- `stdout` receives a single JSON document with a top-level `status` ("success" or "error") — parsable regardless of exit code.

[gemini-code-assist]

The markdown link is split across two lines. Keeping it on a single line improves readability in the source and ensures better compatibility with various markdown parsers.

Suggested change

	errors rather than inspect an exit code), see [Using as a
	Module](#using-as-a-module) below.
	errors rather than inspect an exit code), see [Using as a Module](#using-as-a-module) below.