Task: Disable PostgreSQL TLS for Go production

Identity

Change the Go PostgreSQL adapter so production never negotiates TLS, even when the existing DATABASE_URL contains sslmode=verify-full and sslrootcert from the previous deployment template.
Align the Node migration client, ACK Secret/template checks, Go Deployment, environment example, and deployment guide with plaintext PostgreSQL.
Preserve explicit PostgreSQL selection, credentials, authorization, migrations, pooling, and fail-closed startup behavior.

The user explicitly chose code-side plaintext transport instead of changing Alibaba Cloud RDS SSL configuration and accepted the resulting lack of database link encryption.
A newly built Go image must start with the existing TLS-bearing Secret; no live Secret or RDS control-plane mutation is part of this task.
Work test-first at the configuration/connection seam that reproduced the production server refused TLS connection failure.
Keep the change surgical and do not alter API, authentication, billing, storage, or database schema behavior.

Go ParseConfig removes case-insensitive sslmode/sslrootcert values, writes sslmode=disable, never reads a CA, and records plaintext mode.
Go Open normalizes the URL again and explicitly clears pgx TLSConfig and fallbacks, so a direct or legacy Config cannot negotiate TLS.
The migration Node client and retained server-only TypeScript adapter apply the same normalization and pass ssl: false to pg.
ACK no longer defines or mounts zhinian-rds-ca; migration and Go Secret examples use sslmode=disable.
Environment examples, both READMEs, deployment guidance, and manifest assertions now disclose plaintext PostgreSQL transport and require private network isolation.
No live Alibaba Cloud or ACK configuration was changed.

RED: new Go tests failed because the old parser read sslrootcert, defaulted to verify-full, and Open required TLS configuration.
RED: new Node tests failed because the old clients tried to read a missing CA and the ACK checker found the retained CA mount.
GREEN: go test ./... passed for every backend package.
GREEN: npm test passed 53 files / 160 tests.
GREEN: npx tsc --noEmit --incremental false passed.
GREEN: npm run deploy:check passed all seven checked-in ACK manifests.
GREEN: node --check passed for both modified Node scripts.
GREEN: npm run build exported all 14 static pages successfully.
git diff --check passed with line-ending warnings only.
First read-only sol_reviewer verdict: FAIL because backend/README.md retained TLS claims and tests did not observe a real PostgreSQL startup packet; both findings were fixed.
Final read-only sol_reviewer verdict: PASS on both Standards and Spec after the Go wire test observed plaintext StartupMessage 196608 (not SSLRequest 80877103) and the executable TypeScript configuration test passed.

Build and deploy an immutable Go image, then verify startup bootstrap and /api/ready against the live RDS instance.
Reapplying the database Secret is not required for TLS removal because the new clients override old TLS parameters, but the checked-in plaintext Secret template should be used for future rotations.
Reassess TLS if the network boundary or compliance requirements change.

Target: RDS-001/current architecture/database deployment commitments. Proposal: record that production PostgreSQL transport is intentionally plaintext and code-enforced, superseding the prior verified-CA TLS default. Evidence: production RDS refused TLS, the deterministic diagnosis task 20260816-diagnose-go-rds-tls-9c4a7e21, and the user's explicit 2026-08-16 instruction not to modify Alibaba Cloud and to remove TLS in code. Future impact: future deployment templates and database clients must not silently reintroduce TLS without a new operator decision and compatible RDS configuration. Semantic conflicts: canonical current state and commitments still describe verified-CA TLS as the prior target. Human confirmation required: already received for plaintext production transport; canonical promotion still requires the serialized Integration Gate.