Restrict Release Tag Creation to Authorized Actors (Immutable Tag Governance)

### What

Introduce strict governance for release tag creation across S-CORE repositories in order to:

- Prevent accidental or intentional re-pushing of release tags
- Protect immutability assumptions (e.g. devcontainer image tags)
- Improve traceability and release governance
- Support long-term reproducibility guarantees

Currently, in most repositories, committers can create tags and releases.

Since container images (e.g. ghcr.io/eclipse-score/devcontainer:v1.1.0) and other artifacts are often referenced by tag, tag mutability creates risk:

- Tags can be re-pushed
- A tag can silently point to different content over time
- Consumers referencing :vX.Y.Z may unknowingly receive different artifacts
- This breaks immutability assumptions and reproducibility guarantee

We already enforce strict tag blocking in bazel_registry using Otterdog:

```
newInfrastructureTeamRepo('bazel_registry') {
rulesets+: [
block_tagging(
[
"*",
],
[
"@eclipse-score/infrastructure-maintainers",
]
),
],
}
```

see change from @AlexanderLanin https://github.com/eclipse-score/.eclipsefdn/commit/447b64e11d368ba4367838a640a1981ca69967d3

### How

Step 1 – Identify Scope
---------------------------

Determine which repositories publish:

- Container images (e.g. devcontainer)
- Toolchain artifacts
- Versioned releases consumed by other repos

Step 2 – Define Governance Policy
---------------------------------------

Identify the actors for each repo

Step 3 – Implement via Otterdog
---------------------------------------
Add rulesets similar to bazel_registry:

Step 4 – Optional: Release Workflow Enforcement
------------------------------------------------------------

For stronger governance:

- Enforce releases via GitHub Action only
- Require PR + review before triggering release

### Estimates for realization

Impact to Users of the Feature

- Stronger immutability guarantees
- Improved traceability
- Reduced risk of silent release modification
- Better foundation for reproducible builds

### Category

- [ ] Affects Detailed Design

### Requirements / Architecture

- [x] Requirements / Architecture are not affected by this change?