feat(curl): preserve actual values for single-line JSON API responses

Feature Request

Problem

When fetching JSON data via curl, rtk converts responses to schema format (types only, no values). This is problematic for common use cases where users need actual values, not just types:

$ curl -s "https://api.npmjs.org/downloads/point/last-month/@anthropic-ai/claude-code"
{"downloads":47287350,"start":"2026-03-21","end":"2026-04-19","package":"@anthropic-ai/claude-code"}

# Current rtk output (schema only):
{
  downloads: int,
  start: date?,
  end: date?,
  package: string
}

# Expected rtk output (preserve values):
{
  downloads: 47287350,
  start: 2026-03-21,
  end: 2026-04-19,
  package: @anthropic-ai/claude-code
}

Use Cases Requiring Actual Values

• Package registry stats: npm/pypi/crates downloads, stars, versions
• Health/status checks: /health, /status, /version endpoints
• CI/CD data: environment variables, build metrics, deployment status
• Configuration queries: feature flags, feature toggles, runtime config

Current Workaround

rtk proxy curl <url>   # Bypass filtering entirely
\curl <url>           # Skip hook rewrite

These require manual intervention and break transparency.

Proposed Solutions (Pick One)

1. Single-line JSON skip: If response doesn't contain \n, preserve original values
2. Size-based threshold: JSON under N characters or N fields skip schema conversion
3. Configurable exclusion: exclude_commands = ["curl"] already exists but too coarse

Design Considerations

Per the Design Philosophy:

• Correctness vs Token Savings: Users explicitly fetching JSON data need actual values
• Transparency: Filtered output should remain valid -- a schema isn't valid JSON
• Never Block: Fallback to raw output if filter decision is unclear

Related Issues

• #297: curl JSON size guard (already addresses large payloads)
• #1152, #1157: internal URL skip (localhost/127.0.0.1 bypass)

Discussion Needed

Before implementing, we should discuss:

1. What criteria should determine schema vs values? (line count, size, field count?)
2. Should this be opt-in or change default behavior?
3. Should we distinguish between "data APIs" vs "schema-only useful" responses?