During release init, librarian scans the source_path of the library for gapic_metadata.json files alongside generated client code. When a gapic_metadata.json file contains per-service api_version entries (proto), librarian builds a map of them to include in the generated release notes.

This should handle if multiple api entries in the library being released have api_version information, and differentiate on a gapic_metadata.json property like proto_package or library_package (proto), so that the generated release notes can correlate API versions to services within each package.

The format of the generated release notes can be debated, but should look roughly like the following:

_existing library tag heading..._

### API Versions

<details><summary>`cloud.google.com/go/library/apiv1`</summary>

* LibraryService: 2025-09-14

* ShelfService: 2025-04-04
</details>

<details><summary>`cloud.google.com/go/library/apiv2`</summary>

* LibraryService: 2025-09-14
</details>

_existing feature, fix, documentation headings..._

The use of collapsable sections is potentially important due to the size of some API surfaces (i.e. compute, aiplatform, etc.) that have 10s of service definitions. We may also consider optimizing the generated output in the case where every proto service shares the same API version value.