perf(postgres): stream or clamp LIMIT — avoid full Result buffer

[ZhuchkaTriplesix]

Parent

Part of #414

Problem

injectSqlLimit only helps when the user SQL has no LIMIT. The postgres driver still returns a fully buffered Result. UI then caps displayed rows, but peak allocation already happened.

Huge user LIMIT, multi-statement paths, or inject misses → large Dart buffers.

Evidence

• lib/core/database/postgres_connection.dart (execute → Result)
• lib/features/postgresql/postgres_sql_workspace.dart (~308–365)
• lib/core/database/postgres_sql.dart (injectSqlLimit)

Related

#184 closed after LIMIT injection; this is the remaining buffering gap. MySQL SQL workspace already uses rowsStream as the target shape.

Acceptance

• Peak memory ≈ O(displayed rows), not O(server rows returned) for typical SELECT
• Existing LIMIT larger than cap is clamped (or streamed and stopped at cap)
• Prefer portal/stream fetch when available
• Tests for inject + clamp + multi-statement policy

Suggested fix

Clamp existing LIMIT to _resultMaxRows; use portal / stream fetch; avoid holding full Result when only N rows are shown.

[ZhuchkaTriplesix]

Shipped on dev via #432 (Closes did not auto-close because PRs targeted dev).