Stable release tag is stale — please cut v0.3.0 final

## Summary

The latest **stable** tag is quite stale while development continues on RC tags, which blocks downstream packaging and distro onboarding from tracking a well-defined source snapshot.

- Last stable tag: **v0.2.0** (2026-04-15)
- `HEAD` is **94 commits ahead** of it (as of 2026-09-11)
- The newest tags since then are RC pre-releases (`v0.3.0-rc1.post1, v0.3.0-rc0.post1, v0.2.0`)

## Why it matters for packaging

We are packaging FlagOS components as deb/rpm for distro repos (openEuler/openKylin and our own Nexus repos), and distro builds pin a **stable, reproducible source snapshot**. With RC tags excluded by our release filter:

- building from `v0.2.0` ships a version missing 4+ months of fixes;
- building from an RC tag violates the stable-release rule for distro repos.

For repos where a stable tag is unavailable in time, we fall back to pinning a commit hash — workable, but a proper stable tag is much better for version comparison, upgrades and changelog tracking.

## Request

Could you cut a stable release tag (e.g. promote the current `v0.3.0` line to final, or tag `v0.3.0` from a reviewed commit)? A regular cadence — even "whenever the rc line stabilizes, drop the final tag" — would let downstream packaging follow automatically.

Happy to help with release notes or anything mechanical if useful.

Review the existing v0.2.0 and v0.3.0-rc tags, then compare the current HEAD and the reviewed v0.3.0 line. Confirm which commit should become the stable source snapshot and prepare the final tag and release notes so downstream packaging can use it.

Written by the indexing model from the issue text.