Graphs list shows fallback path ~/logseq/graphs/<name> when LOGSEQ_GRAPHS_DIR is set

Nobody has claimed this yet.

## Environment

- Logseq nightly `20260916` (revision 6bf8fe7), Linux x86_64
- `LOGSEQ_GRAPHS_DIR` set in the process environment (e.g. `~/Documents/Logseq`), feature introduced in a081d01c

## What happened

Data is stored **correctly** under `$LOGSEQ_GRAPHS_DIR//`: the Electron main process and the db-worker both resolve `LOGSEQ_GRAPHS_DIR` (worker args show `--root-dir`/`--graphs-dir` pointing at the custom location, and `db.sqlite` is written there).

However, the **"All graphs" page in the renderer displays the hardcoded default path** `~/logseq/graphs/` instead of the actual location.

## Analysis

`logseq.common.graph/get-db-graphs-dir` reads `js/process.env.LOGSEQ_GRAPHS_DIR` with a fallback to `~/logseq/graphs`:

```clojure
(defn get-db-graphs-dir []
(or (some-> js/process.env.LOGSEQ_GRAPHS_DIR expand-home)
default-graphs-dir))
```

The renderer windows are created with `:nodeIntegration false` (and context isolation), so `js/process.env` is unavailable in the renderer — the graphs-list UI falls back to the default path when building the display string, while the main process / db-worker resolve the env var correctly.

## Expected behavior

The graphs list should show the actual graph directory (ideally resolved by the main process and passed to the renderer via IPC, since the renderer cannot read the env directly).

## Workaround / impact

Display-only: graph creation, opening, and storage all land in the right place. But the wrong path shown in the UI is misleading for users relying on `LOGSEQ_GRAPHS_DIR`.

Start with logseq.common.graph/get-db-graphs-dir and the graphs-list UI path-building logic, then trace how the Electron main process communicates with the renderer. Verify how the resolved LOGSEQ_GRAPHS_DIR can reach the renderer despite disabled Node integration. Done means the All graphs page displays the actual graph directory while graph storage behavior remains unchanged.

Written by the indexing model from the issue text.