feat(aws/rds): connect follow-ups — fewer args, CA trust, and client-binary handling

## Describe the Feature

Follow-up to the RDS IAM authentication work in **#2817** (`atmos aws rds token`) and **#2818**
(`atmos aws rds connect` + the `aws/rds` integration). To let the initial commands land, the following
areas were intentionally deferred. This issue tracks them so `connect` can evolve toward a
`gh auth token`-style, low-friction UX. Related discussion: https://github.com/orgs/cloudposse/discussions/121

### 1. Reduce required arguments for `connect`

Today `atmos aws rds connect` requires `--host`, `--port`, and `--username` (region falls back to the
identity's credential region). A named `aws/rds` integration already collapses these into a single
argument — `atmos aws rds connect ` — reading `spec.database` from
`pkg/schema/schema_auth.go` (`RDSDatabase`). The remaining gaps:

- **Integration auto-select (small, offline).** Support a bare `atmos aws rds connect` when exactly one
`aws/rds` integration is configured, plus a default marker, plus an interactive picker when several
exist — mirroring `resolveIdentityName` in `cmd/aws/rds/token.go`. Change
is confined to `cmd/aws/rds/connect.go`; no new dependencies, fully
unit-testable offline.
- **Tag-based discovery (larger).** Optionally select an instance by AWS tags via
`rds:DescribeDBInstances`. Requires adding `aws-sdk-go-v2/service/rds`, an `RDSClient` wrapper + mock
(mirroring `pkg/auth/cloud/aws/eks.go`), region handling, and selection/ambiguity UX. Introduces a live
API call, so it should be additive and mock-gated.
- **Endpoint discovery from stack outputs.** Resolve host/port from Terraform outputs / stack vars so the
endpoint doesn't have to be typed at all.

### 2. CA-certificate trust strategy

`connect` currently **embeds** the Amazon RDS global CA bundle
(`pkg/cacerts/rds/global-bundle.pem`). Per maintainer feedback
during review, prefer **fetch-on-demand + cache** or **requiring `--ca-bundle`** over a vendored bundle,
and evaluate reusing the existing Atmos caching layer. Verify-full / `VERIFY_IDENTITY` TLS must remain the
default regardless of source.

### 3. Client-binary handling (`psql` / `mysql`)

`connect` shells out to the user's client. Per maintainer feedback:

- **Fail fast** with a clear, actionable error when the required client is missing, reusing the existing
binary-presence helper (as used by hooks/toolchain) rather than a bespoke check.
- **Auto-install `psql`** through the Aqua registry Atmos already consumes (follow the hooks/toolchain
autoinstall pattern).
- **Do not auto-install `mysql`** — it ships only inside the large server archive; document the
prerequisite instead.

### 4. CA-bundle refresh automation

Resolve the `TODO(follow-up)` in `pkg/cacerts/rds/doc.go`: add a scheduled
workflow to re-fetch the Amazon RDS root bundle and open a PR when it changes, so trust can't silently go
stale. (Scope depends on the outcome of item 2.)

## Use Case

`atmos aws rds connect` gives engineers passwordless, IAM-authenticated database access through their Atmos
identity. The friction today is the argument list and the client/cert prerequisites. Reducing required args
(ideally to zero for a configured integration) and handling the client/cert setup gracefully makes it feel
like `gh auth token` — a single command that "just works" — which is the difference between a command people
reach for and one they route around.

## Describe Ideal Solution

- `atmos aws rds connect` with a single (or default) `aws/rds` integration connects with **no flags**.
- Missing `psql` is auto-installed via Aqua; missing `mysql` fails fast with guidance.
- TLS trust needs no vendored bundle and cannot silently go stale.

## Alternatives Considered

- **Keep the embedded bundle** — simplest, but vendors a third-party cert set into Atmos and needs manual
refresh (see item 4).
- **Tag-based discovery instead of integration auto-select** — more magical, but a larger lift (new SDK
dependency, live API, wider IAM) and better layered on top of the offline integration path rather than
as the first step.

## Additional Context

- Builds on: #2817 (token), #2818 (connect / `aws/rds` integration).
- Discussion: https://github.com/orgs/cloudposse/discussions/121
- Suggested sequencing: integration auto-select → CA-trust decision → client fail-fast + `psql` autoinstall
→ tag/endpoint discovery + CA refresh automation.

### Task checklist

- [ ] `connect` integration auto-select + default + picker (`cmd/aws/rds/connect.go`)
- [ ] CA trust: fetch-on-demand + cache **or** require `--ca-bundle`; drop the embedded bundle
- [ ] Client fail-fast on missing `psql`/`mysql` (reuse existing helper)
- [ ] Auto-install `psql` via Aqua; document `mysql` prerequisite (no autoinstall)
- [ ] Tag-based discovery (`rds:DescribeDBInstances`) — additive, mock-gated
- [ ] Endpoint discovery from Terraform outputs / stack vars
- [ ] CA-bundle refresh automation (`pkg/cacerts/rds/doc.go` TODO)

Start with cmd/aws/rds/connect.go and compare its integration handling with resolveIdentityName in cmd/aws/rds/token.go; review pkg/schema/schema_auth.go and pkg/cacerts/rds/doc.go for the named supporting areas. Run the existing AWS RDS tests, then work through the checklist so argument selection, certificate handling, client prerequisites, discovery, and refresh automation are covered.

Written by the indexing model from the issue text.