feat(statusline): honor user-configured location over IP geolocation (#843)

[rpriven]

Problem

The statusline determines location and weather purely via ip-api.com IP geolocation, which returns the wrong city for users behind a VPN, proxy, or corporate network whose exit node is in a different city — then falls back to hardcoded San Francisco coordinates. settings.json already has a .location object (city, regionName, lat, lon) but the statusline ignores it for both display and weather.

Fix

Make settings.json .location authoritative when present:

• Location display uses the configured city / regionName
• Weather uses the configured lat / lon
• Optional .location.countryCode drives the flag emoji (falls back to 🌐 when unset)
• ip-api.com is skipped entirely when location is configured — correct for VPN/proxy users, and one fewer third-party request exposing the user's IP
• IP geolocation remains the fallback for unconfigured users (no behavior change for them)

The .location.* reads are ?-guarded so a malformed user-edited .location (e.g. a string instead of an object) can't break the rest of the settings cache.

Testing

Tested end-to-end on Debian 13 / PAI v5.0.0:

• ✅ Configured location with countryCode → shows configured city + flag, skips ip-api
• ✅ Configured location without countryCode → shows city + 🌐 fallback, skips ip-api
• ✅ Unconfigured → ip-api fallback works exactly as before (verified countryCode populated from ip-api)
• ✅ Partial (city only, no coords) → city displays, weather falls back gracefully (no crash)
• ✅ Malformed .location → guarded; TEMP_UNIT / counts / rest of settings cache intact

Closes #843. Thanks to @DAESA24 for the original analysis and workaround.

[danielmiessler]

Thanks @rpriven, your fix is already live in source and credited inline (upstream PR #1309): user-configured settings.json location is authoritative and ip-api is only the fallback. The repo is generated from our source tree, so we port and close rather than merge. Please pull the latest. Appreciated!

[rpriven]

Thanks Daniel — appreciate the credit, and the port-and-close model makes sense now that the repo's generated.

One heads-up from checking the shipped payload after your note: as of today, main's LifeOS/install/LIFEOS/LIFEOS_StatusLine.sh doesn't seem to carry this fix yet — location still comes only from ip-api (there's no settings-location priority chain like the one timezone has at the top of the file), and I couldn't find the inline credit either. While verifying, I hit the same gap on two other ported fixes: the #1409 memory markers (templates on main still ship without <!-- BEGIN ENTRIES -->, and parseFile() returns empty when markers are missing — same fix independently re-submitted and closed in #1443), and the #1404 $HOME literals (install/settings.system.json lines 5/6/9, confirmed by another user on macOS yesterday).

Easy to reproduce the state: the GitHub blob SHAs for all five relevant files (MemoryWriter.ts, both memory templates, settings.system.json, LIFEOS_StatusLine.sh) are identical between the v6.0.5 tag and main — so none of these files has changed in the public tree since the 7/5 release, i.e. before these ports were closed as handled.

All four look like one mechanism rather than four separate misses: whatever generates the public payload from your source tree may be dropping some ported fixes. Figured one pointer to the pattern was more useful than four bug reports. Happy to re-verify any of these against the next release cut.