Thanks for adding A-index — it's a natural complement to K and SFI, and the implementation is clean. The change follows all existing patterns correctly: AppSettings (not QSettings), both GPU and software paint paths updated symmetrically, and the struct default of -1 for "not yet fetched" is consistent with the existing convention.

One thing worth flagging — cache invalidation on upgrade

loadCache() and setEnabled() now both require aIndex >= 0 before restoring or emitting cached data:

if (k >= 0 && a >= 0 && sfi > 0 && ts > 0) {  // a will be -1 for pre-upgrade cache

Any existing user who upgrades will have PropForecastAIndex absent from their settings, so a reads as -1 and the entire cached forecast is silently dropped. The overlay won't appear until after the first successful network fetch post-launch. For most users this is a ~30–60 second gap at most, and the fetch runs automatically, so it's a minor UX issue — but it is a regression from the current behaviour where the overlay appears immediately.

If you want to preserve the instant-on behaviour through the upgrade, a straightforward fix is to treat a missing a as "old cache format, accept it anyway" by initialising it to 0 (a valid A-index) when the key is absent:

int a = s.contains("PropForecastAIndex")
    ? s.value("PropForecastAIndex").toInt()
    : 0;  // treat absent key as A=0 (valid, won't block restore)

Or simply document the one-time miss as acceptable — either way is fine, just wanted to make sure it was a deliberate choice.

Everything else looks good:

• XML tag <aindex> matches the HamQSL solar feed element name
• toInt() fallback to 0 on a malformed element is safe — A0 is a valid value and the pattern is consistent with K/SFI parsing
• All three setPropForecast call sites in MainWindow.cpp are updated
• showProp guard in both render paths is consistent
• No out-of-scope files touched

Again, nice clean contribution — thank you @jensenpat!