Support Aurora instance autodiscovery and fanout #23

The problem

Problem

An Aurora PostgreSQL endpoint can represent a cluster containing multiple
writer and reader instances.

PgBot currently inspects the instance reached through the supplied connection
string. This can miss instance-specific statistics and findings from other
instances in the cluster.

I would like PgBot to accept one Aurora connection string, discover the
underlying instances, inspect them, and combine the results.

Goals

• Automatically discover Aurora writer and reader instances.
• Run PgBot inspection against every discovered instance.
• Combine results into the existing multi-target output formats.
• Preserve instance identity and writer/reader role in results.
• Require only PostgreSQL connectivity and DNS.
• Do not require AWS credentials, AWS CLI, an SDK, or RDS API access.
• Preserve backward compatibility with --all-databases.

Aurora can contain both multiple instances and multiple logical databases. The
design should consider whether complete inspection requires instance fanout,
database fanout, or both.

Existing functionality

PgBot already supports database fanout through --all-databases, including:

• Target discovery
• Bounded parallel execution
• Combined rendering
• Aggregate exit codes
• Partial failure handling

Aurora fanout may be able to reuse or generalize this functionality.

Possible approaches

These are suggestions rather than requirements:

1. Add a separate Aurora instance fanout flag while sharing the existing
   database fanout implementation internally.
2. Add a generic fanout flag that detects the topology and chooses database,
   instance, or combined fanout automatically.
3. Generalize target discovery so database and instance targets use the same
   internal execution pipeline.
4. Allow database and instance fanout to compose when an Aurora cluster
   contains multiple databases.

Design questions

• Should users explicitly request instance fanout, or should PgBot detect it
  automatically?
• Should Aurora inspection cover every instance, every database, or their
  cross-product?
• How should fanout behave when connected through a pooler that hides native
  Aurora endpoints?
• How should cluster-wide findings be deduplicated?
• How should partial instance coverage appear in output and exit codes?
• Which existing CLI and JSON contracts must remain unchanged?

Acceptance criteria

• One supplied native Aurora endpoint can discover all current writer and
  reader instances.
• Every discovered instance can be inspected without AWS API access.
• Connected instance identity is verified before collection.
• Results from all successfully inspected instances are combined.
• Partial coverage is clearly reported and produces a failure exit status.
• Existing --all-databases behavior remains backward compatible.
• Output remains deterministic and preserves target identity.
• Unsafe or ambiguous endpoint derivation fails instead of guessing.