Resolve bundle product repo from products.yml per product

[Mpdreamz]

BundleBuilder stamped a single bundle-level repo and owner onto every product in the output. Now each product's repo is resolved from ProductsConfiguration via product.Repository, falling back to the bundle-level value when the product is absent from the catalogue or has no explicit repository: field.

Affects: Release notes

Prompt summary: Part of a multi-PR plan to fix elastic/cloud changelog pipeline. elastic/cloud hosts three products (cloud-hosted, cloud-serverless, cloud-enterprise) under one repo. Without per-product resolution, every bundle produced by elastic/cloud stamps the same bundle-level repo onto all products, making PR link rendering and scrubber decisions incorrect for the individual products.

Why

BundleBuilder.BuildProducts set Repo = repo (the bundle-level value) unconditionally on every BundledProduct. For a repo like elastic/cloud that hosts multiple products, the resulting bundle had one repo for all products rather than the correct per-product repo. The downstream scrubber (ChangelogContentScrubber) and inline renderer (ChangelogInlineRenderer) both read BundledProduct.Repo to decide which links to hide — so a wrong value suppresses or exposes the wrong links.

What

Per-product repo resolution in BundleBuilder

BundleBuilder now accepts a ProductsConfiguration? and resolves each product's Repo via a new ResolveProductRepo helper: look up the product in the catalogue and return product.Repository; fall back to the bundle-level repo when the product is missing or its repository: field is null. product.Repository is already defaulted to the product ID when not explicitly set in products.yml.

ChangelogBundlingService wires in the catalogue

The single new BundleBuilder().BuildBundle(...) call in ChangelogBundlingService now passes configurationContext?.ProductsConfiguration as the last argument. No signature change at the call sites outside this service — the parameter is optional.

Backward compatibility

When productsConfiguration is null (or the product is not found), behaviour is identical to before — the bundle-level repo is used. All existing tests pass unchanged.

Verify

dotnet test tests/Elastic.Changelog.Tests/
# BundleBuilderPerProductRepoTests — 5 new cases covering per-product resolution,
# catalogue fallback, and null-catalogue backward compat

Stack: 3 of 5, on top of #4022.