fix(psql): disable startup file loading

[nightcityblade]

Fixes #3395

Summary

• Invoke psql with -X so startup configuration cannot alter the aligned output that RTK parses.
• Avoid duplicating the option when users already pass -X or --no-psqlrc.

Test plan

• cargo fmt --all && cargo clippy --all-targets && cargo test
• Manual testing: rtk <command> output inspected
  • N/A: exact command arguments are covered by test_build_psql_command_disables_startup_file; a live PostgreSQL server is not required for this argument-only change.

Important: All PRs must target the develop branch (not master).
See CONTRIBUTING.md for details.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

nightcityblade seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[HetCreep]

Confirmed the -X fix — built this branch, the unit test passes, and it's the right call for the .psqlrc case.

One flag before this merges: the original report had three separate sub-issues, and this closes only the first. Since the PR says "Fixes #3395", merging into develop will auto-close the whole issue.

Still open, neither touched by this diff:

• NLS translation of the (N rows) footer — ROW_COUNT's regex is English-only (^\(\d+ rows?\)); a non-English lc_messages produces different footer text and the row-count summary misses it. -X doesn't affect this, it's a locale setting, not a startup-file setting.
• A literal | inside a cell value shifts columns — filter_table's trimmed.split('|') still splits unconditionally. I fed a row with a text cell containing a|b through the current filter_table and got 3 columns back instead of 2 (["1", "a", "b"]), silently shifting every field after it. This is the one I'd worry about most since it produces a wrong answer rather than a visible failure.

Not asking for either in this PR — just flagging so they get a follow-up issue instead of disappearing when #3395 closes.