restructure Pi tool formatting into per-method dispatch with generic fallback

[LasmarKhalifa]

Closes #1022

Builds the foundation for the stack by replacing the current tool formatter routing to a per-method dispatch.

[LasmarKhalifa]

• add ls tool formatters #1021
• add find tool formatters #1020
• add grep tool formatters #1019
• add edit tool formatters #1018
• add write tool formatters #1017
• add read tool formatters #1016
• add bash tool formatters #1014
• restructure Pi tool formatting into per-method dispatch with generic fallback #1012 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[mathiusj]

Foundation looks clean — per-method dispatch with respond_to?(..., true) and a generic fallback reads well, and the test rewrite is a nice tightening. A few things to consider before the whole stack lands on top of this.

[mathiusj]

Robustness: dispatch trusts arguments is a well-formed Hash. format_unknown calls arguments.empty?/.map, and downstream formatters do arguments.values_at(...) / arguments[:edits].length. If Pi ever sends a non-Hash (or nil) arguments, or a formatter's typed assumption is violated (e.g. :edits as a String), dispatch raises inside the progress logger. Since this is display-only, the highest-leverage fix lives here in the foundation: wrap the send(format_method_name) in a rescue that falls back to format_unknown. That protects all 7 downstream PRs at once and means per-tool reviewers don't have to scrutinize each formatter's arg assumptions. (Normalizing @arguments to {} when non-Hash in initialize is a cheap complement.)

[LasmarKhalifa]

Added the fallback!