Derive the file-viewer text/binary allowlist from Galaxy's datatype registry

#296 added `.tabular` (plus `.interval` and the fastq quality variants) to the file viewer's text-extension allowlist, because Galaxy downloads tabular datasets as `.tabular` and they were rendering as "Cannot preview -- binary file". As @bgruening noted on that PR, hand-maintaining the allowlist is whack-a-mole -- we keep discovering Galaxy plain-text datatypes we forgot. Galaxy already has the authoritative answer, so we should pull from it instead of curating by hand.

**Today.** Two parallel hand-maintained lists, kept in sync manually:
- `TEXT_EXTS` in `app/src/renderer/files/file-viewer.ts` (renderer `kindOf`, drives the binary placeholder)
- `TEXT_PREVIEW_EXTS` in `app/src/main/files-handler.ts` (main-process `isTextLikeForPreview`, gates large-file head previews)

**Proposal.** Derive the text-extension set from Galaxy's datatype registry. Galaxy registers each datatype with a class (text datatypes subclass `data.Text` / `Tabular`; binaries subclass `Binary`) and a mimetype, exposed over `/api/datatypes?extension_only=false`. Build the allowlist from "datatypes that are text" rather than a literal list.

**Constraint that shapes the design.** The file viewer is shell-side and runs on local files -- it can't assume a live Galaxy connection. So this can't be a hard dependency on `/api/datatypes`. Plan:
- Ship a **bundled snapshot** of the text-extension set generated from a Galaxy datatype dump.
- **Refresh opportunistically** when a Galaxy connection is available, caching the result.
- **Fall back** to the bundled snapshot (and ultimately the current static list) when offline.

**One gotcha:** prefer the class hierarchy (subclass-of-`Text`) over mimetype as the text signal -- some Galaxy text datatypes carry `application/*` mimetypes, so mimetype alone would misclassify them.

Follow-up to #296.