feat(ci): automated release notes generation with per-component versioning and GitHub Release integration

[kongche-jbw]

Summary

This issue tracks the implementation of a fully automated release notes pipeline
for the ANOLISA monorepo. The goal is to produce accurate, structured, per-component
changelogs that are usable directly as GitHub Release bodies — with zero manual
editing required for standard releases.

Motivation

Currently there is no automated tooling that:

• Generates changelogs scoped to individual sub-projects (cosh, agentsight,
  agent-sec-core, os-skills)
• Links changelog entries back to the originating PR or Issue
• Surfaces user-facing impact in a format suitable for external release notes
• Publishes GitHub Releases automatically when a version tag is pushed

As the project scales and release cadence increases, manual changelog maintenance
becomes error-prone and time-consuming.

Proposed Changes

1. Per-component changelog with git-cliff

Use git-cliff with a shared cliff.toml
at the repository root. Each sub-project is versioned independently using
monorepo-aware tags (e.g. cosh/v2.1.0, agentsight/v1.3.0).

• Scope filtering — commits are attributed to a component via --include-path
• Noise filtering — chore, ci, docs, test, build, style commits
  are excluded; only feat, fix, perf, and BREAKING CHANGE appear
• Breaking changes first — BREAKING CHANGE entries are rendered in a
  dedicated top section before all other entries
• PR/Issue linking — each entry automatically appends (#<number>) by
  extracting the reference from the commit trailer or PR merge message

2. ## User Impact section in PR template (feat PRs)

For feat-type PRs, contributors are required to fill in a ## User Impact
section in the PR body describing the change from a user perspective. This field
serves as the human-readable source for the changelog entry, distinct from the
technical commit message.

The prelint.yml PR lint gate will enforce this for feat-scoped PRs.

3. Tag-triggered GitHub Release workflow (release.yml)

When a version tag matching <component>/v* is pushed (e.g. cosh/v2.1.0):

1. Run git-cliff for the tagged component, scoped to <prev-tag>..<new-tag>
2. Create a GitHub Release with:
   • Title: <component> v<x.y.z>
   • Body: generated changelog (Breaking Changes → Features → Fixes → Performance)
   • Each entry linked to the originating PR/Issue via (#<number>)
3. Send a DingTalk notification summarising the release (version + feature count)

4. Manual fallback (changelog.yml)

For cases where a release needs to be drafted ahead of tagging, a
workflow_dispatch-triggered workflow allows generating the changelog for any
component and tag range on demand, with the output opened as a PR for maintainer
review.

Acceptance Criteria

• Pushing cosh/v2.1.0 tag automatically creates a GitHub Release with
  changelog scoped to src/copilot-shell/
• Each changelog entry includes (#<number>) linking to the originating PR
• BREAKING CHANGE entries appear in a dedicated top section
• chore, ci, docs commits do not appear in the changelog
• feat-type PRs without a ## User Impact section are rejected by prelint
• DingTalk notification is sent on release creation

Scope

• Multiple / Project-wide (CI infrastructure)

[github-actions]

🔀 Issue Triage

This issue has been automatically assigned to @kongche-jbw @samchu-zsl as the maintainer(s) of cosh.

Maintainers, please review and triage this issue. Set a priority label and update the status as needed. Thanks! 🙏