feat(chain): dot chain properties <name> (slice 1 of #199)

[peetzweg]

Implements slice 1 of #199 — a thin, self-contained dot chain properties <name> command. (Deliberately not "Closes": #199 tracks slices 2–5 and open decisions, so it stays open.)

Why: dot doesn't surface a chain's properties block, so users and the dot-cli skill hardcode token decimals per chain (NATIVE_DECIMALS=12 vs 10). Run a script against the wrong network and every balance is off by orders of magnitude. The chain knows the answer — ask it.

How: New src/core/chain-properties.ts fetches via system_properties and falls back to chainSpec_v1_properties (see defaults below), normalizing to { tokenDecimals, tokenSymbol, ss58Format }. chain.ts adds a properties subcommand that resolves the chain by its saved name (like chain info/update) and prints JSON or a human-readable block.

Real output (dot chain properties polkadot --json):

{
  "tokenDecimals": 10,
  "tokenSymbol": "DOT",
  "ss58Format": 0
}

So scripts can do: NATIVE_DECIMALS=$(dot chain properties polkadot --json | jq .tokenDecimals).

Defaults chosen for the issue's open questions:

• RPC source: try system_properties first (universally implemented → fewest failed round-trips), fall back to chainSpec_v1_properties. Both return the same shape.
• Multi-token / array responses: preserved verbatim in the JSON (not collapsed to the first element).
• Empty {} properties: each field degrades to null; no crash.

Out of scope / still open: slices 2–5 (persist to config.json, balance rendering, --from-spec, full chain-spec import) and the caching-policy decision remain in #199. The RPC-source and array-handling choices above are proposed defaults, not final rulings.

Tests: unit tests for the fetch/normalize logic (scalar, array, empty, fallback, all-fail) plus end-to-end command tests driving the real RPC client against a local WebSocket JSON-RPC server. Changeset + README + SKILL + scripting-patterns docs updated with executable examples.