Point connect failures at --tls disable

[openai0229]

What

A database that does not serve TLS fails with the default verify-full, and some drivers do not say so: Oracle reports ORA-17002: I/O 错误: Connection closed (which reads like a network fault) and the local test flow used by the README never mentions the flag.

When the connection fails before the first statement (index empty, outcome not_started) and the datasource uses verify-full, the CLI now appends (the connection failed before any statement; if this database does not serve TLS, retry with --tls disable) to the error message. Statements that already ran, unknown outcomes and --tls disable connections are untouched, so a mid-batch failure never suggests changing the transport.

Verification

Against the four local containers, each datasource created with the default TLS mode:

MySQL       mysql.execution_failed    | … invalid peer certificate: UnknownIssuer (the connection failed before any statement; if this database does not serve TLS, retry with --tls disable)
PostgreSQL  postgres.execution_failed | error performing TLS handshake (… retry with --tls disable)
Oracle      jdbc.08006.17002          | ORA-17002: I/O 错误: Connection closed, … (… retry with --tls disable)
SQL Server  jdbc.08S01.0              | "Encrypt"… 无法使用 SSL 建立安全连接… (… retry with --tls disable)

• cargo fmt --all -- --check, cargo clippy --workspace --all-targets --locked -- -D warnings passed.
• cargo test -p ottermind-sqlx adds a unit test covering all four branches (before-any-statement, after-a-statement, unknown outcome, TLS already disabled).

Risks and limits

• The hint is additive text on connection failures; it can appear for a non-TLS cause such as a wrong password, where the conditional wording still applies.
• Found while testing this change, not fixed here: an Oracle connection failure writes 55 lines of driver diagnostics to stderr (32 of them 信息:/stack frames), which buries the message. That belongs in a separate change.