chore: instalar workflows gh-aw de ambito organizacional

[svg153]

Summary

Instala en svg153-org/.github los workflows gh-aw que son claramente de ambito organizacional o multi-repo, en lugar de mantenerlos en repos producto.

Workflows incluidos

• ospo-contributors-report
• ospo-org-health
• ospo-release-compliance-checker
• ospo-stale-repos

Como se han traido

Se han importado desde sus fuentes oficiales con gh aw add, manteniendo el campo source: para facilitar updates posteriores.

Customizaciones locales

• ospo-org-health: default operativo a svg153-org y schedule fuzzy semanal
• ospo-stale-repos: default operativo a svg153-org
• README.md: documenta instalacion, update y validacion con gh aw

Validation

• gh aw validate ospo-contributors-report ospo-org-health ospo-release-compliance-checker ospo-stale-repos
• git diff --check

Why

Estos workflows gobiernan varios repos o reporting/compliance de cartera, asi que su home correcta es el repo .github de la organizacion, no cada repo de producto.

[Copilot]

Pull request overview

Este PR traslada e instala en el repo organizacional svg153-org/.github varios workflows de gh-aw pensados para uso multi-repo/organizacional, junto con su documentación de operación y los artefactos compilados (*.lock.yml) para ejecución en GitHub Actions.

Changes:

• Añade 4 workflows agentic (*.md) de OSPO y sus lockfiles compilados (*.lock.yml) importados desde github/awesome-copilot manteniendo source:.
• Documenta en README.md el flujo reproducible de instalación/actualización/validación con gh aw.
• Marca los lockfiles como generados y define estrategia de merge vía .gitattributes.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
README.md	Documenta instalación, actualización y validación de workflows gh-aw en el repo organizacional.
.github/workflows/ospo-contributors-report.md	Workflow agentic para reporte mensual de contribuciones.
.github/workflows/ospo-contributors-report.lock.yml	Workflow de GitHub Actions compilado por gh aw compile (artefacto generado).
.github/workflows/ospo-org-health.md	Workflow agentic para reporte semanal de salud de la organización (con defaults locales).
.github/workflows/ospo-org-health.lock.yml	Workflow de GitHub Actions compilado por gh aw compile (artefacto generado).
.github/workflows/ospo-release-compliance-checker.md	Workflow agentic para chequeo de compliance de releases OSS (comment en issue).
.github/workflows/ospo-release-compliance-checker.lock.yml	Workflow de GitHub Actions compilado por gh aw compile (artefacto generado).
.github/workflows/ospo-stale-repos.md	Workflow agentic para identificar repos “stale” y publicar reporte como issue (default org local).
.github/workflows/ospo-stale-repos.lock.yml	Workflow de GitHub Actions compilado por gh aw compile (artefacto generado).
.github/aw/actions-lock.json	Lock de acciones usadas por gh-aw (pinning por SHA).
.gitattributes	Marca lockfiles como generados y define estrategia de merge para *.lock.yml.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

.gitattributes uses merge=ours for *.lock.yml, but Git doesn't ship an ours merge driver by default (only text, binary, union). Without configuring merge.ours.driver in repo/local git config, merges can error with an unknown merge driver. Consider either documenting the required git config merge.ours.driver true setup for contributors/CI, or switching to a built-in merge behavior (e.g., treat these files as binary and regenerate via gh aw compile after merges).

Suggested change

	.github/workflows/*.lock.yml linguist-generated=true merge=ours
	.github/workflows/*.lock.yml linguist-generated=true merge=binary

[Copilot]

safe-outputs.create-issue is configured to always apply the stale-repos label. Creating/updating an issue will fail if that label doesn't exist in the target repo. To make the workflow more robust, either (a) document that the .github repo must pre-create the stale-repos label, or (b) change the workflow to add the label only when it exists (similar to how ospo-contributors-report treats optional labels).