feat: shared CI workflows, release automation, Renovate presets and org defaults

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,57 @@
+---
+name: Bug report
+about: Report a problem, something that does not work as expected
+title: ""
+labels: ""
+type: "Bug"
+assignees: ""
+---
+
+<!--
+No personal data, credentials, instance names, hostnames or other client-specific details here.
+Scrub logs and screenshots before adding them; link to internal sources (e.g. a Sentry issue) instead.
+Security vulnerabilities: do not open an issue, see SECURITY.md (report them privately).
+-->
+
+## What
+
+<!-- What happens, and what you expected to happen instead. -->
+
+## Why
+
+<!-- Impact: who is affected (users, administrators, operators), how often, is there a workaround? -->
+
+## How to reproduce
+
+<!-- Steps, request or configuration that triggers it.
+     Version (app version or image tag), relevant configuration, (scrubbed) logs or a link to the error in monitoring. -->
+
+---
+
+Implementation plan: <!-- link to the plan comment, added once the cause and fix are agreed -->
+
+<!--
+IMPLEMENTATION PLAN (not part of this description)
+
+Once the objective above is agreed, post the implementation plan as ONE comment on this issue and
+link it above. It is for the developer or agent implementing the change and must be
+self-contained: someone who reads only that comment and the code can implement it without the
+rest of the discussion. When decisions change, edit that comment in place instead of adding new
+ones; change this description only if the objective changes.
+
+## Implementation plan
+
+### Context
+The current state, verified against the code: file paths, how it behaves today. Anything assumed
+but not verified is marked as such.
+
+### Decisions
+Each decision with its reason and the rejected alternative, including how risks are handled.
+
+### Changes
+Concrete steps: files, config keys, snippets where precision matters, then the tests and docs to
+add or change.
+
+### Open questions
+What is still undecided and how it gets settled. Omit when there are none.
+-->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,60 @@
+---
+name: Feature request
+about: Suggest a new functionality
+title: ""
+labels: ""
+type: "New Feature"
+assignees: ""
+---
+
+<!--
+No personal data, credentials, instance names, hostnames or other client-specific details here.
+Scrub logs and screenshots before adding them; link to internal sources (e.g. a Sentry issue) instead.
+Keep this description short and readable for non-developers. Technical details go into the
+implementation plan comment (see the guidelines at the end of this template).
+-->
+
+## What
+
+<!-- The intended outcome, as observable behaviour: who can do what afterwards?
+     e.g. "As an administrator I want to ... in order to ..."
+     Also state what is explicitly out of scope. -->
+
+## Why
+
+<!-- The problem or use case behind it, and who is affected (users, administrators, operators). -->
+
+## How
+
+<!-- The proposed approach in a few sentences, and alternatives considered.
+     A small table or list helps to compare options. -->
+
+---
+
+Implementation plan: <!-- link to the plan comment, added once the objective is agreed -->
+
+<!--
+IMPLEMENTATION PLAN (not part of this description)
+
+Once the objective above is agreed, post the implementation plan as ONE comment on this issue and
+link it above. It is for the developer or agent implementing the change and must be
+self-contained: someone who reads only that comment and the code can implement it without the
+rest of the discussion. When decisions change, edit that comment in place instead of adding new
+ones; change this description only if the objective changes.
+
+## Implementation plan
+
+### Context
+The current state, verified against the code: file paths, how it behaves today. Anything assumed
+but not verified is marked as such.
+
+### Decisions
+Each decision with its reason and the rejected alternative, including how risks are handled.
+
+### Changes
+Concrete steps: files, config keys, snippets where precision matters, then the tests and docs to
+add or change.
+
+### Open questions
+What is still undecided and how it gets settled. Omit when there are none.
+-->

.github/ISSUE_TEMPLATE/technical_task.md

@@ -0,0 +1,58 @@
+---
+name: Technical task
+about: A technical improvement, e.g. operations, observability, dependencies, CI or infrastructure
+title: ""
+labels: ""
+type: "Task"
+assignees: ""
+---
+
+<!--
+No personal data, credentials, instance names, hostnames or other client-specific details here.
+Scrub logs and screenshots before adding them; link to internal sources (e.g. a Sentry issue) instead.
+Keep this description short and readable for reviewers. Technical details go into the
+implementation plan comment (see the guidelines at the end of this template).
+For pure refactorings without behaviour change, set the issue type to "Code Quality / Refactoring".
+-->
+
+## What
+
+<!-- The intended outcome, as observable behaviour. What is explicitly out of scope. -->
+
+## Why
+
+<!-- The problem and who is affected (users, administrators, operators, developers). -->
+
+## How
+
+<!-- The approach in a few sentences. A small table or list helps to compare options or parts. -->
+
+---
+
+Implementation plan: <!-- link to the plan comment, added once the objective is agreed -->
+
+<!--
+IMPLEMENTATION PLAN (not part of this description)
+
+Once the objective above is agreed, post the implementation plan as ONE comment on this issue and
+link it above. It is for the developer or agent implementing the change and must be
+self-contained: someone who reads only that comment and the code can implement it without the
+rest of the discussion. When decisions change, edit that comment in place instead of adding new
+ones; change this description only if the objective changes.
+
+## Implementation plan
+
+### Context
+The current state, verified against the code: file paths, how it behaves today. Anything assumed
+but not verified is marked as such.
+
+### Decisions
+Each decision with its reason and the rejected alternative, including how risks are handled.
+
+### Changes
+Concrete steps: files, config keys, snippets where precision matters, then the tests and docs to
+add or change.
+
+### Open questions
+What is still undecided and how it gets settled. Omit when there are none.
+-->