[docs] - Clarify stable & development image tags availability and contribution rules. - #2030

Summary

Clarifies the availability of stable and experimental dev-* images across all image READMEs and directs users to live MCR data for currently pullable tags.

Closes #1965 and . Is a Rework of PR #1972
Also helps with Issues like #1963 (That is already resolved but similar issues might occur, this PR prevents that)

Current Issues

As of today, one of the crucial images, Universal, displays different versions as 'Latest' across its documentation and registries:

1. Version 6.1.8 appears in the Universal README, which users commonly consult as a reference.
2. Version 6.1.6 appears on the MCR artifact page.
3. Version 6.1.7 appears on the MCR tags page.

Root Cause

Dev images are built from main and published under mutable dev-* tags, while stable images follow a versioned release flow. During release preparation, prepare-release.sh applies a manifest patch bump and updates matching README version references. Because changes can reach main before stable publication, static README examples may temporarily reference tags that are not yet pullable.

This is primarily caused by the following:

• The current documentation does not clearly distinguish between stable and development tags, which can confuse new users.
• The current Copilot review instructions do not account for the two artifact publication modes: stable releases and development tags published directly from main.
• Manual README version bumps merged into main can reference unreleased tags and create invalid or confusing links.
• As a result, the three sources are not always synchronized.

Changes

Updated all 18 image READMEs to include copyable stable references, separate MCR detail and tag links, a valid experimental dev-* example, guidance that dev tags may change in place, reproducibility recommendations, and clarification that semantic-version examples are usage references.

Added contributor and Copilot guidance requiring semantic manifest bumps for every image-changing PR, README updates for major and minor changes, and no manual README patch updates for security or bug-fix changes.

Approaches Considered

1. Lifecycle-Aware README Sections and Release Script

Pros: Preserves automatic stable-version updates, prevents unrelated README content from being modified, and gives stable, development, and pinned tags explicit documentation boundaries.

Cons: Introduces a rigid Markdown-heading contract that requires additional tests and maintenance, while pins could still be updated before MCR publication succeeds.

2A. Separate Stable and Dev Documentation

Pros: Clearly separates stable and experimental artifacts, keeps dev variants documented before stable release, and allows each tag type to follow its own lifecycle.

Cons: Requires recurring documentation work before scheduled or manual dev pushes and duplicates MCR data as another synchronization point. MCR already provides the authoritative tag inventory, so delaying dev documentation reduces its early-discovery and validation value.

2B. Update READMEs Only During Stable Releases

Pros: Prevents development changes from appearing immediately as stable examples, reduces README edits during development, and lets release automation use the final version.

Cons: Dev variants may be published without repository documentation, while post-publication updates require additional commits, documentation PRs, rollback handling, and workflow state.

2C. Use MCR for Current Availability

Pros: Uses registry-backed data for current tags, digests, and publication state; keeps stable and experimental images discoverable; and requires no additional release-state or rollback automation.

Cons: Static semantic-version examples may briefly lead stable publication, so users must consult MCR when selecting a currently available version.

Why We Selected 2C

This approach preserves early discovery and validation of changes from main, separates copyable image references from browser links, and avoids additional release-workflow complexity. Major and minor changes remain visible in dev builds before stable publication, while security and bug-fix PRs avoid manual README patch churn. Release preparation still synchronizes those patch references.

This approach was selected during the team meeting after considering the viable alternatives.

Validation

Confirmed the documented stable and dev-* references, reviewed the wording across all 18 image READMEs, passed git diff --check, and passed all four prepare-release.sh regression tests.

Caveat

Static semantic-version examples may briefly lead stable publication, so users should consult MCR for current availability. Existing release automation remains unchanged; lifecycle-aware post-publication updates could remove this window if the additional workflow complexity becomes justified.