Define standard README warning and topics for archived API repositories

[albertoramosmonagas]

Problem description
Today, when we archive an API repository as part of the Lifecycle Clean-up Process, there is no consistent pattern for how the repository status is communicated in the README and metadata:

• Some repos (e.g. DeviceStatus) include a custom warning/note at the top of the README, others do not.
• There is no standard text explaining that the repo is archived, how it relates to successor APIs (if any), or how it ties back to the API Backlog decision and the lifecycle documentation.

With the unified Lifecycle Clean-up Process now in place, we need a consistent, documented pattern for how archived repositories should look and how they should reference the API Backlog issue and the lifecycle document.

Expected action
Define a standard warning/note block to be added at the top of the README of any API repository that is archived, including:

• A clear statement that the repository is archived and only kept for maintenance of previous releases.
• Links to: The API Backlog issue where the archival was decided, the Lifecycle / Clean-up Process section in Governance and any successor repositories or replacement APIs, when applicable.
• Specify the required GitHub topics for archived API repositories, including adding archived-api-repository and removing previous maturity topics (e.g. sandbox-api-repository, incubating-api-repository).
• Document this pattern (text + formatting example) in the Governance / Lifecycle documentation so that future archival transitions can follow the same template.

Additional context

• Example of a warning section already used in a repo: DeviceStatus README: https://github.com/camaraproject/DeviceStatus/blob/main/README.md
• Governance / Lifecycle Clean-up Process section (archiving Sandbox/Incubating/Graduated repositories).
• Recent archival proposals in API Backlog (e.g. HomeDevicesQoD, SiteToCloudVPN, ShortMessageService) that will need a consistent README/banner and topic configuration once the pattern is agreed.