fix: preserve response value types

[chaim0m]

Summary

• remove automatic agent-mode string truncation
• preserve OpenAPI scalar types in JSON, TOON, and table output
• remove the now-unused --full and --no-truncate flags
• cover both response shaping and the table-column filter with strings longer than the former limit

Why

Follow-up to Alfredo's review comment on #33. Automatic truncation changed strings into objects, broke schema consumers, increased TOON encoding overhead, and could hide an entire table column.

Test methods

go test ./...
go vet ./...

Could this break things?

Risk: low-medium, intentionally removes unreleased behavior. Agent output can be larger for unusually long values, but values retain their documented type and full content. The unreleased --full and --no-truncate flags disappear because there is no automatic truncation to disable.

Jira

CMP-48644

[apgiorgi]

This is the change I asked for and it's correctly scoped to just the truncation half. Verified the bug independently: truncation replaced a string with map[string]interface{}{"value","_truncated"}, and filterObjectColumns (main.go:2425-2441) hides any column where any row contains a map — so a single >2000-rune value deleted that column from the table for every row, not just the long one. It also broke jq -r, typed unmarshal, and type: string conformance.

Also confirmed this isn't a UX regression: table output stays bounded by its own layer (--table-mode fit, --table-max-col-width, truncateText at main.go:2525), all untouched, and --fields/--exclude remain as size controls. Removing --full/--no-truncate is safe since they were introduced in the same unreleased branch — v1.5.1 doesn't contain them, so no released CLI ever accepted those flags. Cleanup is complete; no dangling references to agent-full, agent-no-truncate, or truncateResponseValue anywhere.

Two nits, neither blocking:

• output_contract_test.go:23 — strings.Repeat("a", 2009) is now a bare magic number. It used to be defaultAgentTruncationLength+9; a short comment ("longer than any prior truncation limit") would keep the intent readable.
• No regression test at the layer where the bug was actually visible. A filterObjectColumns case with a 3000-char string would stop this from being reintroduced — the current test asserts the type/value survives, which wouldn't have caught the column-dropping behavior.

On the prefix: this removes never-released behavior, so chore: fits better than fix: per AGENTS.md. Otherwise the next changelog shows feat: add agent response projection and truncation next to fix: preserve response value types, which reads oddly. Minor, and there's precedent on main for the current usage.

[chaim0m]

Addressed both valid nits: the former 2,000-character boundary is now named in the regression, and filterObjectColumns has direct coverage proving a long string does not make the table column disappear. go test ./... and go vet ./... pass. I did not rewrite the already-published commit solely to change its prefix because that would require a force-push.

[josuesilva-doit]

LGTM

[chaim0m]

Both non-blocking requests remain addressed after merging current main: the former limit is named and the table-column regression is covered directly. The focused suite and go vet ./... pass. Re-requesting the required review on the current head.