docs: add technical release engineering concept

[ds-jhartmann]

Description

This PR adds a new documentation page, docs/technical-release-engineering.md, proposing a Technical Release Engineering (TRE) capability for Eclipse Tractus-X. It is a documentation-only change — no code, no workflow and no change to the current release process.

The concept addresses a gap in release validation: today it relies largely on manual coordination, on a shared integration environment (INT) that drifts between releases, on automation whose maturity differs per product, and on evidence spread across several systems. The proposal adds a technical layer on top of the existing process rather than replacing it.

What the document covers

• preliminary assessment of the current release and testing situation, and the gaps a TRE capability would close
• target operating model with seven capabilities, plus roles and ownership
• nine proposed quality gates with a minimum evidence model
• release governance model: versioning guidelines, approval and exception handling, gate operationalisation, and how the gates attach to the existing release checks and sig-release/release-automation
• four evaluated options with a recommendation: a parallel validation environment built on tractus-x-umbrella, running alongside the current process
• conceptual target architecture, toolchain recommendation (CI/CD, artefact management, security checks) and engineering best practices
• pilot approach, risks, dependencies and open decisions
• seven Mermaid diagrams

Also included

• README.md: added the document to the "See … for information about" list
• docs/tractus-x-release.md: cross-reference from the qualification-process section, framed as a proposal under discussion

Explicitly not agreed yet

This is a proposal for discussion, not a decided model. In particular:

• items marked provisional need confirmation before they become binding, and Section 13.4 lists the open decisions
• the hosted validation environment is the only element requiring recurring funded infrastructure and has no identified owner — until that is resolved, only the GitHub-native lightweight (kind) track can be assumed
• Section 6.2 proposes roles for SIG Release, the Tractus-X project leads and Catena-X e.V.; none of these parties has committed to them, and any role for Catena-X e.V. needs its explicit consent as a separate legal entity
• the smoke-test declaration in Section 10.1 suggests extending the .tractusx metadata file, which is TRG-owned and would require a TRG change request

Feedback on scope, on the governance proposal and on the funding question is what this PR is looking for. I would like to present it in a Community Office Hour before it is merged.

Prepared in the context of the Catena-X Next roadmap item "Concept for Technical Release Engineering" (tracked in the non-public catenax-eV/sig-roadmap).

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

• DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs. — documentation-only change; no dependencies added or changed, DEPENDENCIES untouched.
• Copyright and license header are present on all affected files — the new page carries a NOTICE block with SPDX identifiers. Question for committers: I used CC-BY-4.0, per NOTICE.md declaring that for non-code, but the existing pages in docs/ all use Apache-2.0. Happy to switch for consistency if preferred.