docs: rewriting OCM OCI repository mapping (#134)

<!-- markdownlint-disable MD041 -->
#### What this PR does / why we need it

The specification defines how OCM repositories, component descriptors,
and artifacts are stored and resolved inside OCI registries.
It standardizes the repository format, how component names map to OCI
paths, and how versions are represented using either OCI manifests or
OCI indexes.
It prescribes strict rules for descriptor selection, LocalBlob handling,
digest validation, and version-to-tag mapping.
The specification also introduces a Component Index artifact used for
referrer-based version discovery and defines fallback mechanisms for
registries lacking referrer support.

#### Which issue(s) this PR is related to
<!--
Usage: `Related to #<issue number>`, or `Related to (paste link of
issue)`.
-->

This completely revamps the OCI mapping specification and makes it much
more detailled and normative so we can base our multiple client
implementations on it.

fixes open-component-model/ocm-project#718
based on
open-component-model/open-component-model#1048

---------

Signed-off-by: Jakob Möller <[email protected]>

Author: jakobmoellerdev

doc/03-persistence/02-mappings.md

@@ -2,19 +2,24 @@
 
 This chapter describes how OCM model elements are mapped to elements of a persistence layer.
 
-OCM model elements are mapped to various storage technologies. The interoperability layer for a client tool is typically the API of the storage backend. This avoids the need for providing an OCM server infrastructure.
+OCM model elements are stored using various backend technologies. The interoperability layer for a client tool is typically the API of the chosen storage backend, avoiding the need for a dedicated OCM server.
 
-An implementation of this layer MUST implement this mapping by supporting the [mandatory abstract model operations](./01-operations.md#mandatory-operations). It SHOULD implement the [optional operations](./01-operations.md#optional-operations) too.
+An implementation of this layer **MUST** support the [mandatory abstract model operations](./01-operations.md#mandatory-operations).  
+It **SHOULD** support the [optional operations](./01-operations.md#optional-operations).
 
 ## Storage Backend Mappings for the Open Component Model
 
-The OCM specification describes an interpretation layer on-top of well-known storage backend technologies used to store OCM component versions.
-
-Therefore, for every storage technology a mapping must be defined to ensure interoperability between different OCM implementations.
+The OCM specification provides an interpretation layer on top of storage technologies used to persist component versions.
 
+For every supported technology, a mapping **MUST** be defined to ensure consistent interoperability across implementations.  
 These mappings describe:
 
-- the repository specification type and format used to specify a dedicated repository instance
-- the mapping of the OCM elements to the elements provided by the storage technology.
+- the repository specification type and format for identifying a repository instance, and
+- how OCM model elements are mapped to the artifacts or structures provided by that backend.
+
+These mappings are defined as part of the [extensions](../04-extensions/03-storage-backends/README.md).
+
+## Note on OCI Storage Backends
 
-The mappings are defined as part of the [extensions](../04-extensions/03-storage-backends/README.md)
+The OCI storage backend mapping now supports **both manifest-based and index-based representations** of component versions.  
+The detailed rules and normative behavior of the index-based format are defined in the corresponding OCI backend extension.