Clarify stale workflow policy for demonstration repositories

[yada]

Context

The organization workflow in .github/workflows/global-replicator.yml excludes repositories listed in DEMONSTRATIONS from STALE-ISSUES replication. However, some excluded demo repositories still contain local copies of .github/workflows/stale-issues-prs.yml. These copies are no longer centrally maintained and have started to drift.

This central issue follows the repository-level report:

• Refs: Decide whether stale automation is useful for this demo repository microcks-testcontainers-dotnet-demo#106

Observed inconsistencies

microcks-testcontainers-dotnet-demo

• Explicitly listed in DEMONSTRATIONS and therefore excluded from stale-workflow replication.
• Still contains an active stale workflow using actions/stale v10.4.
• Dependabot opened chore(deps): bump actions/stale from 10.4.0 to 11.0.0 microcks-testcontainers-dotnet-demo#100 to update it to v11.
• The repository currently has no open issues; its open pull requests are Dependabot updates.

microcks-aspire-demo

• Explicitly listed in DEMONSTRATIONS and therefore excluded from stale-workflow replication.
• Still contains a stale workflow using actions/stale v10.1.
• The workflow is disabled due to inactivity.
• The repository has no .github/dependabot.yml, so no GitHub Actions update is proposed.
• The repository currently has no open issues or pull requests.

Comparison: microcks-quarkus-demo

Although this is also a demonstration repository, it is not present in the DEMONSTRATIONS exclusion list. It therefore received the centrally managed v11 stale workflow through microcks/microcks-quarkus-demo#238 and continues to run it successfully.

Decision needed

We should define one consistent policy for stale automation in demonstration repositories:

1. Remove stale automation from excluded demo repositories and delete the remaining local workflow copies. This is the recommended option for low-traffic demos with no issue backlog.
2. Include the needed and relevant demo repositories in centralized STALE-ISSUES replication when stale handling is useful.
3. Keep repository-specific workflows, accepting that each demo repository must maintain its own workflow and Dependabot configuration.

Whichever option is selected, the DEMONSTRATIONS scope should be reviewed so similarly positioned repositories such as the .NET, Aspire, and Quarkus demos are treated intentionally and consistently.

Proposed follow-up

• Confirm which demo repositories should use stale automation.
• Remove obsolete local workflow copies from excluded repositories, or adjust the STALE-ISSUES replication exclusions.
• Resolve the related Dependabot PRs according to that decision.