FileBrowser: extension parsing produces garbage ext for files without a dot

[kovtcharov]

Summary

In src/gaia/apps/webui/src/components/FileBrowser.tsx, two spots build an extension string without first guarding .includes('.'), so a dotless filename produces an invalid extension like .README (the full filename) that gets shown to the user as the supposed unsupported file type.

Locations

• FileBrowser.tsx:284 — handleIndexSelected
• FileBrowser.tsx:340 — handleAskAgent

const firstFile = files[0];
const ext = '.' + firstFile.split('.').pop()?.toLowerCase();
// firstFile = 'README'  →  ext = '.readme'  ← wrong

Compare with the correct guarded form at lines 106, 279, and 526:

const ext = filepath.includes('.') ? '.' + filepath.split('.').pop()?.toLowerCase() : '';

Reachability

Only triggered when all selected files are unsupported by extension AND the first one has no dot. Unlikely in normal flows (the outer isExtensionSupported walk already rejects dotless files as supported, so execution rarely reaches these branches with a dotless first file), but it leaks a misleading error string to the user.

Suggested Fix

Extract a helper and use it everywhere:

function getExt(filepath: string): string {
    return filepath.includes('.') ? '.' + (filepath.split('.').pop() ?? '').toLowerCase() : '';
}

Then replace the two raw sites with getExt(firstFile) / getExt(files[0]). Also useful in UnsupportedFeature.tsx:239 and DocumentLibrary.tsx:216.

Impact

• UI polish only — the user sees a wrong extension label in an error toast.
• Fits v0.18.2 UI polish scope if prioritized, otherwise vFutures.