[1839] Fix: Truncate status.deploy.stdout as it can exceed etcd's limit on large clusters, causing reconciliation delay

[himsngh]

What this PR does / why we need it:

On large clusters (>~250 nodes), a kapp deploy can produce several MiB of change output (one line per resource per node). kapp-controller writes this verbatim into status.deploy.stdout and then calls UpdateStatus on the App CR. etcd rejects objects larger than its hard 2 MiB gRPC message limit, causing the status write to fail repeatedly. The deployment itself has already succeeded, only the status update is failing but the App stays in ReconcileFailed until a subsequent no-op reconcile produces a small enough diff to fit.

This PR fixes the issue by truncating individual status output fields to 1 MiB before they are written into the status struct. When truncation occurs the field is prefixed with [output truncated]\n so operators immediately know the field is incomplete rather than receiving silently clipped output. The tail of the output is kept (not the head) because the most actionable content, the final resource summary and any error lines, always appears at the end of kapp output.

Fields covered: status.deploy.stdout, status.deploy.stderr, status.fetch.stdout, status.fetch.stderr, status.inspect.stdout, status.inspect.stderr, status.usefulErrorMessage.

Which issue(s) this PR fixes:

Fixes #1839

Does this PR introduce a user-facing change?

NA

Additional Notes for your reviewer:

Review Checklist:

• Follows the developer guidelines
• Relevant tests are added or updated
• [-] Relevant docs in this repo added or updated
• [-] Relevant carvel.dev docs added or updated in a separate PR and there's
  a link to that PR
• Code is at least as readable and maintainable as it was before this
  change

Additional documentation e.g., Proposal, usage docs, etc.: