CLI: `read` subcommands for PRT dispute entities (`tournaments`, `commitments`, `matches`, `match_advances`)

[vfusco]

Context / Problem

The CLI currently exposes read epochs|inputs|outputs|reports, but there is no way to inspect PRT dispute data from the local database via the CLI.
Node operators and developers need a quick, app-scoped way to list/query PRT dispute entities with the same semantics and filters available through the JSON-RPC API.

---

Suggested Solution

Add four new read subcommands:

• cartesi-rollups-cli read tournaments ...
• cartesi-rollups-cli read commitments ...
• cartesi-rollups-cli read matches ...
• cartesi-rollups-cli read match_advances ...

Implementation notes:

• Follow the same UX patterns as existing read commands (epochs, inputs, outputs, reports): positional args for <application-name-or-address> plus an optional identifier, and common pagination flags (--limit, --offset) where applicable.
• The CLI must not implement custom SQL/query logic. It must call the repository layer and reuse the same query semantics already exposed by JSON-RPC.
• Filters/parameter names and response shapes must match what is specified in internal/jsonrpc/jsonrpc-discover.json (i.e., the CLI should be a thin wrapper over the repository calls used by the JSON-RPC handlers).

---

Deliverables

• Add new Cobra commands under:
  • cmd/cartesi-rollups-cli/root/read/tournaments/tournaments.go
  • cmd/cartesi-rollups-cli/root/read/commitments/commitments.go
  • cmd/cartesi-rollups-cli/root/read/matches/matches.go
  • cmd/cartesi-rollups-cli/root/read/match_advances/match_advances.go
• Wire the commands into cmd/cartesi-rollups-cli/root/read/read.go
• Ensure commands use the same configuration approach as existing read commands (Cobra + Viper; DB connection via flag + env var)

---

Acceptance Criteria

#	Scenario & Expected outcome
1	cartesi-rollups-cli read --help lists: tournaments, commitments, matches, match_advances
2	For each new command, running with only <app> returns a list response (paginated if applicable) and exits with code 0
3	For each new command, running with <app> <id> (when the JSON-RPC method supports fetching a single item) returns exactly that item (or a clear “not found” error)
4	CLI output matches JSON-RPC output for the equivalent method and parameters, using normalized JSON comparison: jq -S . on both outputs must be identical
5	Pagination flags behave consistently with existing commands: --limit N --offset M returns the same slice as the JSON-RPC method for the same inputs
6	Invalid identifier / invalid filter value causes a non-zero exit code and a human-readable error (no stack trace in default mode)