fix(apps): show actually-installed tag instead of latest after older-version install

[rainxchzed]

Field-reported bug: install an older release of an app via the Details screen version picker → the system reports the correct (lower) version, but GHS Apps + Details screens keep showing the latest tag instead of the one the user picked.

Root cause

`PackageEventReceiver.onPackageInstalled` post-install update was pulling the displayed `installedVersion` from `app.latestVersion` — that field is GHS's cached "what GitHub says is the latest tag", not what the user just installed. So an explicit older-version install would land the correct APK in the OS but render the latest tag in our UI.

The `if (wasActuallyUpdated)` happy path used `app.latestVersion ?: systemInfo.versionName` for `newTag` (correct under the assumption the user always installs the latest — broken by the version picker). The else-branch added in PR #541 used the same wrong source.

Fix

Both branches now read the parked tag from `app.pendingInstallVersion` first — that field is set by `DefaultDownloadOrchestrator.parkForUser` to the exact `releaseTag` the user requested via the Details version picker. Falls back to `app.latestVersion` then `systemInfo.versionName` if the parked tag was somehow not persisted.

```kotlin
val installedTag =
app.pendingInstallVersion
?: app.latestVersion
?: systemInfo.versionName
```

Used in:

• `if (wasActuallyUpdated)` → `repo.updateAppVersion(newTag = installedTag, ...)`
• else-branch → `installedVersion = installedTag` in the column-only update

Happy-path behaviour is unchanged for normal latest-version updates: `pendingInstallVersion` equals `latestVersion` in that case.

Test plan

• `:core:data:compileDebugKotlinAndroid` ✅
• Local CodeRabbit: 1 finding in untracked `RELEASE_NOTES_1.8.1.md` (out-of-scope) → skipped.
• Manual:
  • Install a tracked app via Details → Older versions picker → pick v1.0 (with v1.5 latest available). Confirm system shows v1.0, GHS Apps + Details now show v1.0 too.
  • Normal update flow on another app → still shows latest tag correctly.
  • Update Available badge: app with installed v1.0 still flags v1.5 as available (`isUpdateAvailable` derived from `latestVersionCode > systemInfo.versionCode`, which still works).

Summary by CodeRabbit

• Bug Fixes
  • Enhanced app installation version tracking to correctly display installed versions, particularly for pending installations and explicit older-version installs. The system now derives version information from multiple sources for more reliable version display.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c1587536-adb5-4595-998c-bec877a32b28

📥 Commits

Reviewing files that changed from the base of the PR and between 9dbce7a and 533f51f.

📒 Files selected for processing (1)

• core/data/src/androidMain/kotlin/zed/rainxch/core/data/services/PackageEventReceiver.kt

---

Walkthrough

The PackageEventReceiver.onPackageInstalled method now centralizes version tag determination for pending installs. When a pending-install app's system package is detected, the receiver derives a single installedTag from a prioritized chain—pendingInstallVersion, then latestVersion, then versionName—and applies it consistently to both success and non-success update paths.

Changes

Pending Install Version Tag Logic

Layer / File(s)	Summary
Pending Install Version Tag Resolution core/data/src/androidMain/kotlin/zed/rainxch/core/data/services/PackageEventReceiver.kt	installedTag is derived once from app.pendingInstallVersion, app.latestVersion, or systemInfo.versionName; used in updateAppVersion when wasActuallyUpdated is true; used in updateApp and to advance installedVersion when not updated; included in broadcast tag logs.

Estimated Code Review Effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

📦 A version tag springs into being,
From pending heights to system's seeing—
One truth to rule them, installed and bright,
No more the old tag holds the night. ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically summarizes the main fix: displaying the correct installed version tag after installing an older release, which is the core issue addressed in this PR.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/older-version-installed-tag

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}