fix: contextual argument parsing errors with field name and expected type

Summary

When parseTypedArg fails in tx.ts, the error surfaces as a raw JS error (e.g., inner[tag] is not a function) with no context about which argument failed, what type was expected, or what value was provided.

The parseStructArgs loop (line ~500) and parseCallArgs tuple path (line ~473) have no try/catch wrapping, so failures propagate without useful context.

Example

$ dot tx XcmPallet.reserve_transfer_assets ... <malformed arg>
Error: inner[tag] is not a function

Should instead say something like:

Error: Invalid value for argument 'dest' (expected VersionedLocation): "bad_value"
  Hint: VersionedLocation expects a variant like V4({ parents: 1, interior: ... })

Proposed Changes

• src/commands/tx.ts: Wrap parseTypedArg calls with try/catch that adds:
  • Argument index and field name
  • Expected type description (from metadata)
  • The value that failed to parse
• src/commands/tx.test.ts: Test that malformed args produce contextual error messages

Related Issues

• #65 (structured error codes) — this is scoped to argument parsing only. #65 is the broader error infrastructure.
• #46 (camelCase normalization) — related UX improvement for input handling.

Priority

P1 — Immediately reduces frustration with complex calls like XCM. Quick win (size S).

Start in src/commands/tx.ts by reading parseCallArgs around line 473, parseStructArgs around line 500, and their parseTypedArg calls. Then inspect src/commands/tx.test.ts and add coverage for malformed arguments. Done means parsing failures identify the argument index or field name, expected type, and supplied value without exposing only the raw JavaScript error.