feat(learn): extract generalizable patterns instead of raw command pairs

Problem

rtk learn outputs raw command pairs like:

Use `aws ec2 describe-security-groups --group-ids sg-<ID> --query 'SecurityGroups[0]...' --output yaml`
not `aws ec2 authorize-security-group-egress --group-id sg-<ID> --ip-permissions IpProtocol=tcp,FromPort=8443...`

These are 200+ character commands that are too specific to be useful as reusable rules. The real lesson is: "prefer describe-* with --output table/yaml over piping JSON through inline python".

In production testing (62 sessions, 60 days), rtk learn found 44 corrections but only 1 recurred with --min-occurrences 2. The signal-to-noise ratio is too low for varied infrastructure work (Terraform, AWS CLI, kubectl, GitHub API). The feature works well for repetitive build/test/lint cycles where the same typo recurs, but most infrastructure corrections are one-off and context-dependent.

Proposed Improvement

Add pattern generalization in learn/detector.rs that extracts the principle behind a correction rather than the exact commands:

Common transformation patterns to detect

How it could work

1. After find_corrections() produces raw pairs, a new generalize_correction() step would:
   • Detect if the wrong command uses shell pipelines (|, inline scripts) while the right command uses native flags
   • Detect if both commands target the same base tool but differ in output formatting strategy
   • Detect common flag corrections (grouping by changed flag, not full command)
2. deduplicate_corrections() would group by transformation type rather than exact diff token
3. report.rs would output the generalized principle with one concrete example, not the full raw commands

Example output

Instead of the current:

Use `aws ec2 describe-security-groups --group-ids sg-<ID> --query '...' --output yaml`
not `aws ec2 describe-security-groups --group-ids sg-<ID> --query '...' --output json | python3 -c "..."`

Output:

Prefer native --output (table/yaml) over piping JSON through inline scripts (seen 3x)
  Example: aws ec2 describe-* ... --output yaml  (not ... | python3 -c "...")

Scope

• learn/detector.rs — new generalization step after correction detection
• learn/report.rs — output format for generalized rules
• Significant change to the deduplication and reporting logic

This is a design proposal — happy to discuss the approach before implementing. The key question is whether generalization should happen in the detector (changing what's stored) or the reporter (changing how it's displayed).

Start by reading learn/detector.rs, learn/report.rs, and the existing correction and deduplication flow. Compare the detector-versus-reporter options described in the issue, then define how generalized rules and one concrete example should be represented and reported. Done means varied corrections produce useful grouped principles without losing recurrence counts or examples.