fix(desktop): keep title bar path segments in order under the Bidi algorithm - #5317

Thanks for tracking this down, @dronov-dmitry. The reordering is real, but replacing direction: rtl with text-align: right introduces two layout regressions. I measured each variant in Chromium using the title bar's markup and CSS.

Regressions

1. Long paths now hide the filename (GH#339 is back). When inline content overflows its line box, CSS aligns it to the start edge and it overflows at the end edge, whatever text-align is set to (CSS Text 3, text-align). With LTR, the end edge is on the right. The leading folders stay visible, while the filename and the unsaved dot are clipped (in my test the filename's right edge was 248px past the clip edge). direction: rtl was there to put the overflow on the left.
2. Titles are no longer centered. The span used to inherit text-align: center from .title. text-align: right overrides that, so every title (including the MarkText placeholder) is pushed against the right padding.
3. The unsaved dot now touches the filename. Under RTL the dot was drawn to the left of the title, and margin-right: .25rem provided the gap. In LTR it follows the filename, and the margin ends up on its far side.

Root cause

This isn't a DirectWrite/FreeType difference. It's the standard Unicode bidi algorithm, and Chrome on macOS renders report.md_003 too. In an RTL paragraph, the digits 003 only stay in place if a strong LTR character comes before them. Otherwise they resolve as RTL, _ stays at the paragraph level, and the runs swap.

It only shows up on Windows because the breadcrumb segments never render there. window.path.sep comes from pathe, which is always /, and titleBar/index.vue:217 splits the raw Windows pathname on it. C:\Users\me\Desktop\003_report.md produces no segments, so nothing precedes the digits. On Linux, e.g. Desktop › comes first and keeps them in order. That split is a separate bug and should be fixed on its own.

The PR also doesn't handle RTL folder names. With a Hebrew folder (Users › מסמכים › 003_report.md), this version still renders the segments out of order.

Suggested fix

Keep the RTL box for the left-side clipping, and isolate the LTR content inside it:

<span v-else>
  <bdi dir="ltr">
    <span v-for="(path, index) of paths" :key="index">…</span>
    <span class="filename" …>{{ filename }}</span>
    <span class="save-dot" :class="{ show: !isSaved }" />
  </bdi>
</span>

div.title > span {
  /* Workaround for GH#339 */
  display: block;
  direction: rtl;
  overflow: hidden;
  text-overflow: clip;
  white-space: nowrap;
}
div.title > span > bdi > span {
  unicode-bidi: isolate;
}
.active .save-dot {
  margin-left: 0.25rem; /* instead of margin-right */
}

Measured in Chromium:

Other notes

• Please drop bag_windows_0.19.1.png from the commit. It's a binary at the repo root (committed with mode 100755) that's only used by the PR description. A PR comment attachment works for that.
• The new CSS comment describes the change ("replaced … with …") and gives the Windows explanation. Once the fix above is in, the original /* Workaround for GH#339 */ is enough.