[2.x] fix: keep a saved falsy setting in settings modals too

[imorland]

Follow-up to #4782, which fixed this in AdminPage while the identical line in SettingsModal survived. Same defect, different file — context in #4781.

// AdminPage.tsx — fixed by #4782
this.settings[key] = this.settings[key] || Stream<string>(app.data.settings[key] ?? fallback);

// SettingsModal.tsx — this PR
this.settings[key] = this.settings[key] || Stream(app.data.settings[key] ?? fallback);

Settings live in a string column, so a saved false arrives as an empty string. Choosing the fallback on falsiness discarded it and reseeded the default, which meant a boolean setting whose default is truthy could not be switched off — it came back on with every reload.

Why it matters

SettingsModal is public API — extensions import it as flarum/admin/components/SettingsModal. Current consumers:

• core: EditCustomHeaderModal, EditCustomFooterModal, EditCustomCssModal
• flarum/audit: LimitedSettingsModal

Tests

The existing AdminPageSetting.test.ts (added in #4782) now covers both classes side by side rather than only the one the original issue named — which is what would have caught this the first time round. Seven tests: four for AdminPage, three for SettingsModal.

I checked the new SettingsModal empty-string test fails without this change.

Its docblock is also corrected. It claimed a saved '0' was discarded too, but the string '0' is truthy in JavaScript — only the number is falsy. The empty string is the only value a setting can hold that JavaScript reads as absent.

All integration suites green: 50 suites, 169 tests. check-typings clean.

Testing by hand

Awkward to demonstrate in core, since none of the three core modals has a boolean setting with a truthy default — the visible effect there is nil. It reproduces through an extension that puts such a setting in a modal. The test coverage is the real assurance here.