Keep file explorer aligned during folder expansion

[den-sq]

Summary

• keep every folder row on the same layout class while lazy children populate
• remove the obsolete empty-folder margin that shifted entries horizontally
• preserve the existing file indentation and always-visible folder chevron behavior

Closes #118

Validation

• npm run build
• npx --no-install eslint src/renderer/src/components/MenuPanel/components/FileExplorer/components/DraggableEntry/DraggableEntry.tsx
• npx --no-install prettier --check src/renderer/src/components/MenuPanel/components/FileExplorer/components/DraggableEntry/DraggableEntry.tsx src/renderer/src/components/MenuPanel/components/FileExplorer/components/DraggableEntry/DraggableEntry.module.css
• git diff --check

Shared-basis audit

• Inspected the DraggableEntry row classes and the existing file-explorer panel overflow behavior.
• Reused the canonical folder row class for both unloaded and populated folders; the panel already reserves vertical scrollbar space with overflow-y: scroll, so no competing scrollbar mechanism was added.
• Load-bearing decision: true-empty and lazy-unloaded folders now share the same geometry as populated folders because every folder already owns an always-visible chevron. File indentation is unchanged.
• Approved overlapping mechanisms: none.

Branch basis

• Rebased directly onto origin/main at 691cc56 after Pin server image base by digest #129 merged; this PR remains unstacked.

[tavateva]

APPROVE — @ 9292738a. Correct, minimal root-cause fix for #118. (Draft PR; and my approval is pull-only — it records but den-sq's push rights are what land it.)

The fix is the root cause, not a band-aid

#118 guessed two candidates; this PR found and fixed the real one:

• Cause #1 — the actual bug. .emptyFolder carried margin-left: 1rem. Since #112 made every folder render a chevron (showChevron = isFolder), that margin was a pre-#112 relic: back when empty folders had no chevron, the 1rem faked the chevron's width to keep names aligned. With the chevron now always present, the margin only pushed unopened (lazy-empty) folders 1rem right — and on first expand, isEmpty flipped false → class flipped to .folder (margin 0) → the row jumped 1rem left. Dropping .emptyFolder and always using styles.folder deletes the flip. ✅
• Cause #2 — scrollbar reflow — was already handled. The tree container is overflow-y: scroll (FileExplorer.module.css:25), so the gutter is always reserved and expansion can't steal horizontal pixels. The body's audit says exactly this, and it checks out — so the margin was the only culprit and this fix is complete, not partial.

Grounded checks at head:

• All folders now share .folder (padding-left 0, no margin) + an always-visible chevron → empty and populated folders align identically; files stay at .file margin-left: 1rem; nested .children indent (1.2rem) unchanged. Geometry stays consistent.
• .emptyFolder is referenced nowhere else in src/ — safe removal.
• isEmpty is still live — it gates the children container (DraggableEntry.tsx:149), so no dead variable / no unused-var break.
• The type ternary reformat is prettier-only; no behavior change.

The red CI check is pre-existing and unrelated — not this PR

"Build linux release artifacts" fails, but at the npm run audit:release step (scripts/validate-npm-audit.mjs), which flags @terascope/fetch-github-release, extract-zip, js-yaml, nanoid — transitive advisories the gate hasn't whitelisted (it approves only react-router* / GHSA-qwww-vcr4-c8h2). This diff changes no dependencies (2 files, a CSS module + a TSX), so it can't have introduced them; the gate is red repo-wide for any renderer PR that triggers the release build. It's non-required — the PR reads MERGEABLE / UNSTABLE (a required failure would read BLOCKED; I couldn't read branch protection on pull-only, so that's inferred from mergeStateStatus). coverage and resolve-pr-build are green, and the author's local npm run build + eslint + prettier cover the change itself.

Two non-blocking asks:

1. Worth a one-line note in the PR body that the release-artifact red X is the pre-existing npm-audit gate, not this change — so it isn't read as a regression at merge time.
2. The underlying audit backlog (4 advisories currently failing the release build for every renderer PR) is a separate maintenance item worth its own issue — not part of this fix.

Verification depth

Read the diff, the full DraggableEntry.tsx / .module.css, and the FileExplorer container CSS at head 9292738a; pulled the failed job log to pin the audit-gate cause. CI outcomes (coverage / resolve-pr-build green; release build red) relied on as reported by GitHub — I did not run the renderer build locally.