[SYNC: FVH → laurigates] Adopt reusable-renovate.yml (App-token Renovate runner)

[laurigates]

What

FVH's reusable-renovate.yml has no counterpart in this repo (just diff-upstream reports it as upstream-only). It is a workflow_call Renovate runner already parametrized via inputs (app-id, username, git-author, autodiscover, autodiscover-filter, repositories) with a GITHUB_TOKEN fallback when no App is configured.

Why

This repo currently relies on renovate.json config only, with no reusable runner workflow. Adopting the reusable workflow would let laurigates app repos call a single centralized Renovate job (App-token auth, ghcr host rules) the same way FVH repos do — closing the last genuine upstream→downstream workflow gap.

How / Decision needed

• Port reusable-renovate.yml from FVH; genericize the input-description examples (fvh-renovate-bot[bot] → <renovate-bot>[bot], ForumViriumHelsinki/* → <owner>/*). The logic contains no hardcoded org values.
• Decision (blocks adoption): does laurigates want App-based Renovate? It requires provisioning a GitHub App + a RENOVATE_APP_PRIVATE_KEY secret (via gitops/). If not desired, the workflow still functions through the GITHUB_TOKEN fallback path (no App) — adopt without the App and skip the secret.
• Verify with just leak-check + just lint after porting.

Acceptance

• reusable-renovate.yml exists here, passes just lint and just leak-check, with example strings genericized.
• Decision recorded on whether to wire an App token or run via GITHUB_TOKEN fallback.