Detect whether PostgreSQL plans can be captured at all, and say so — the shippable first slice of #2538 #2564

Child of #2538. This is the piece that can ship before the mechanism question is settled, and it is worth having on its own.

Today a PostgreSQL target silently has no plans. Whatever mechanism #2538 eventually picks, auto_explain is the one that matters most on Aurora/RDS — and whether it is loaded is detectable right now, read-only, with no configuration change:

• SHOW shared_preload_libraries / pg_settings says whether auto_explain is loaded.
• If loaded, auto_explain.log_min_duration says whether it is actually capturing anything (-1 means loaded but capturing nothing, which looks identical to not-loaded from the outside).
• pg_available_extensions says whether it could be.

This is exactly the precondition shape from #2546/#2557, which now exists: a runtime-mutable, operator-fixable fact, evaluated at read time rather than gated at connect. Someone who changes the parameter group and reboots gets picked up on the next cycle without a service restart.

Why this earns its place independently

The failure it fixes is silence. A user evaluating us against DBM on Aurora finds no plans and cannot tell whether we do not support plans, their server is not configured for them, or something is broken. Those need different actions and we say nothing.

The remedy is a real, specific instruction — on Aurora/RDS, auto_explain goes in a custom cluster parameter group and needs a writer reboot; it is not a SET — so this is advice someone can act on, not a shrug.

Notes

• auto_explain.log_min_duration = -1 (loaded, capturing nothing) is the trap: report it as distinct from not-loaded.
• Do not claim plans are being captured merely because the library is loaded — that is a separate fact from whether we can read them.