Spec follow-ups from the docs drift sweep: FsError, on-chain param refs, dynamic map keys

[StreamDemon]

Summary

Three small spec-side gaps surfaced by the #45 docs drift sweep (PR #52). The sweep fixed the docs against the current spec; these are the places where the spec needs a decision. Bundle into the next convenient amendment.

Items

1. The fs error type is unnamed. docs/examples/cli-tool.md now uses Io(FsError) as the From path for fs::read failures, but no spec or stdlib page ever names the error type std::fs returns (docs/stdlib/fs.md is a stub). Worse, the spec's own §6.4 load_config example propagates fs::read(path).context(...)? into an AppError that has no fs-error variant and no From path — the same legality hole the sweep fixed in cli-tool.md. Decide the canonical fs error type name (recommend FsError, matching JsonError/NetError/ChainError convention), add it to §6.4's example as a variant, and give docs/stdlib/fs.md at least the error-type line.

2. On-chain pub-param reference rule — intended or not? docs/web3/onchain-overview.md claimed "no references in public function parameters" for on-chain functions; §11 states no such rule, so the sweep deleted the bullet. But every §11 example does use owned params, and extern onchain mod signatures are owned-only in practice. If the restriction is intended (ABI encoding has no reference semantics), state it normatively in §11 with a diagnostic code; if not, nothing further.

3. Dynamic-length map keys in storage layout. docs/web3/storage-and-state.md carried a keccak256 rule for String/bytes map keys that §11.1a never specifies (§11.1a covers value-type keys only; the sweep deleted the doc-side rule). If dynamic-length keys are meant to be supported, §11.1a needs the rule (Solidity precedent: hash the raw byte content without length prefix, concatenated with the slot); if not, §11.1a should say explicitly that Map keys are restricted to value types on-chain (and which diagnostic fires).

Acceptance criteria

• Each item either lands as normative spec text (with mirrors swept) or is explicitly rejected with the reasoning recorded.
• §6.4's example is legal under its own error-handling rules.