Chronograf 1.10.9 - with multiple connections defined, after opening Log viewer, current connection resets to default

__Steps to reproduce:__

1. Create two or more connections to backend influx databases, e.g. v1 and v3 with v1 as the defalut
2. Activate the non-default connection, e.g. v3
3. Shutdown the v1 database temporarily.
4. Open Influxdb Admin - databases are listed
5. Open logs - wait a few minutes for search
6. Abandon search by returning to Configuration - see that the current connection is now set to the default, e.g. v1
7. Open Influxdb Admin again - error message appears "Unable to administer InfluxDB. Failed to load databases"

__screencast__

https://github.com/user-attachments/assets/821ee9ee-5bd4-4b55-b278-355cfe1d8029

__Expected behavior:__
When selecting a connection for working with other controls in Chronograf, that connection should remain selected until the user switches to a different connection.

__Actual behavior:__
After viewing Logs, the current connection is switched to the default.

__Environment info:__

* Chronograf version: Chronograf 1.10.9 (git: 48e3546b) - n.b. also noted when testing newest release.
* OS: Ubuntu 24.04
* Browser: Opera 126.0.5750.59
* InfluxDB Versions:
* Influxdb1 OSS - docker - started then shutdown as noted in reproduction steps
* Influxdb3 Core - docker

__Config:__
Copy any non-default config values here or attach the full config as a gist or file.

Startup command:

```
$ ./chronograf --influxdb-v3-support-enabled
```
__Logs:__
Include a snippet of errors in the log.
```
...
INFO[1238] Response: OK component=server method=GET remote_addr="[::1]:57328" response_time=2.405617ms status=200
INFO[1238] Response: OK component=server method=POST remote_addr="[::1]:57328" response_time="898.451µs" status=200
INFO[1238] Response: OK component=server method=POST remote_addr="[::1]:57328" response_time="955.608µs" status=200
INFO[1238] Response: OK component=server method=POST remote_addr="[::1]:57328" response_time="810.896µs" status=200
INFO[1238] Response: OK component=server method=POST remote_addr="[::1]:57328" response_time=3.561042ms status=200
INFO[1238] Response: OK component=server method=POST remote_addr="[::1]:57334" response_time=4.550032ms status=200
INFO[1238] Response: OK component=server method=GET remote_addr="[::1]:57334" response_time="724.383µs" status=200
INFO[1238] Response: OK component=server method=POST remote_addr="[::1]:57334" response_time=1.740706ms status=200
INFO[1241] Failed to retrieve database version error="Get \"http://localhost:8086/ping\": dial tcp 127.0.0.1:8086: connect: connection refused" url="http://localhost:8086"
INFO[1241] Response: OK component=server method=GET remote_addr="[::1]:57334" response_time=2.546572ms status=200
INFO[1241] Response: OK component=server method=GET remote_addr="[::1]:57334" response_time="733.801µs" status=200
INFO[1241] Response: OK component=server method=GET remote_addr="[::1]:57328" response_time="718.732µs" status=200
INFO[1244] Response: OK component=server method=GET remote_addr="[::1]:57328" response_time="34.776µs" status=200
ERRO[1245] Error message Error contacting source component=server http_status =400
INFO[1245] Response: Bad Request component=server method=GET remote_addr="[::1]:57328" response_time="491.716µs" status=400
ERRO[1245] Error message Post "http://localhost:8086/query?db=&epoch=ms&q=SHOW+DATABASES&rp=": dial tcp 127.0.0.1:8086: connect: connection refused component=server http_status =400
INFO[1245] Response: Bad Request component=server method=GET remote_addr="[::1]:57334" response_time="699.266µs" status=400
INFO[1254] Response: OK component=server method=GET remote_addr="[::1]:33300" response_time="34.314µs" status=200
INFO[1264] Response: OK component=server method=GET remote_addr="[::1]:48382" response_time="67.387µs" status=200
...
```

Start by reproducing the connection reset through the listed Logs and Configuration steps, then trace how the selected connection is stored and restored when moving between those views. Verify the selected non-default connection remains active after abandoning a log search, including when the default database is unavailable, and confirm InfluxDB Admin still loads from the selected connection.

Written by the indexing model from the issue text.