One bad connection block silently stops ALL connections from syncing until restart

Describe the bug

A single connection block with a duplicate name (or an invalid schema name) permanently stops Steampipe from syncing any connection config, while the service continues to look healthy.

The chain:

1. loadConfig (pkg/steampipeconfig/load_config.go) returns an error for the whole load when one connection block has a duplicate name or an invalid schema name.
2. LoadConnectionConfig re-parses the entire config folder, so that error recurs on every call.
3. ConnectionWatcher.handleFileWatcherEvent (pkg/connection/connection_watcher.go) returns early when the load reports an error — before calling RefreshConnections.

So for as long as the offending block exists, no file event ever reaches RefreshConnections. Connections written after that point never get a schema and never get a row in steampipe_connection_state; updated credentials in rewritten .spc files are never applied. The file watcher itself keeps running (it keeps registering new files), and existing connections keep answering queries, so from the outside the service looks fine.

The only log line is [WARN] error loading updated connection config: ..., which is not visible at the default log level — so there is no operator-visible signal at all.

Steps to reproduce

Service mode, config folder with a number of connections that are being written/updated by an external process:

1. Start the service and confirm connections load (select * from steampipe_internal.steampipe_connection_state).
2. Add a .spc file declaring a connection name that already exists in another file.
3. Write any new connection config file, or update an existing one.

Expected: the new/updated connection is applied; the duplicate is reported. Actual: nothing is applied — ever. steampipe_connection_state freezes at the moment the duplicate appeared, no schema is created for anything added afterwards, and rewritten credentials are never picked up. Restarting the service surfaces the real cause immediately:

Error: duplicate connection name: 'conn_a'
	(/home/steampipe/.steampipe/config/conn_a.spc:1)
	(/home/steampipe/.steampipe/config/conn_a_duplicate.spc:1)

I reproduced this on a service-mode deployment with a few hundred connections whose config files are generated by an automated process. The failure is easy to hit in that setup and hard to diagnose, because the symptom (new connections never becoming queryable, credentials going stale) points nowhere near the actual cause.

Expected behavior

A problem with one connection should disable that connection, not every connection. The rest of the config should continue to load and sync, and the failure should be visible at default log levels.

Proposed fix

Skip the offending connection with a warning rather than failing the whole load, and log the config-load failure at ERROR level so it is visible. PR to follow.

Steampipe version

v2.4.4