test(frontend): pin which refusal a connection string gets

The two messages differ in what they ask the user to do, and the condition
choosing between them — whether the lowercased name is one the resource keeps —
is not visible from either call site. `Connect_Timeout` is the case that keeps
them honest: miscased *and* unstorable, so respelling it would not help and the
message must not suggest it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

frontend/src/lib/utils/postgresConnectionString.test.ts

@@ -1,6 +1,7 @@
 import { describe, expect, it } from 'vitest'
 import {
 	composePostgresConnectionString,
+	connectionParamRefusal,
 	parsePostgresConnectionString,
 	unsupportedConnectionParam
 } from './postgresConnectionString'
@@ -161,3 +162,25 @@ describe('unsupportedConnectionParam', () => {
 		expect(unsupportedConnectionParam('postgres://u:p@h/db')).toBeUndefined()
 	})
 })
+
+// One refusal reached the user through two very different causes, and the wrong explanation
+// sends them to fix the wrong thing: respelling a parameter this resource cannot store changes
+// nothing, and removing one it can store loses what the string asked for.
+describe('connectionParamRefusal', () => {
+	it('blames the spelling only when the parameter is one the resource keeps', () => {
+		expect(connectionParamRefusal('postgres://u:p@h/db?SslMode=verify-full')).toContain(
+			'case-sensitive'
+		)
+		expect(connectionParamRefusal('postgres://u:p@h/db?SslMode=verify-full')).toContain('sslmode')
+	})
+
+	it('blames the resource when respelling would not help', () => {
+		const refusal = connectionParamRefusal('postgres://u:p@h/db?Connect_Timeout=1')
+		expect(refusal).toContain('cannot store')
+		expect(refusal).not.toContain('case-sensitive')
+	})
+
+	it('says nothing about a string it can save', () => {
+		expect(connectionParamRefusal('postgres://u:p@h/db?sslmode=require')).toBeUndefined()
+	})
+})