ci: replace the PR-title bump script with release-please

[mogita]

Ticket

CHA-2963. Fifth repo, after getstream-go, stream-py (#287), getstream-ruby (#86) and getstream-php (#65).

Problem

The bump script derived the version from the merged PR title and then tagged, released and pushed to NuGet from a single job. One unreleased feat: is sitting on master right now because that job failed on 2026-09-10.

Solution

release-please keeps the bump in a reviewable Release PR, and the suite runs before anything irreversible.

• release-please-config.json / .release-please-manifest.json, manifest seeded at 16.0.0. No last-release-sha: this workflow pushed its bump commit to master, so v16.0.0 is reachable and the csproj, the tag and NuGet all agree.
• .NET has no first-class release-please strategy, so this is simple plus an xml extra-file at /Project/PropertyGroup/Version. The simple strategy also looks for a version.txt, which does not exist here and is a no-op.
• src/stream-feed-net.csproj is pre-normalized to the serialization the XML updater emits. BaseXml reparses and rewrites the whole document, so without this the first Release PR would carry whitespace churn on four PackageReference lines next to the version bump. dotnet restore passes on the normalized file.
• The tag, the GitHub Release and the NuGet push are irreversible, so a detect job finds the merged Release PR waiting to be tagged and the suite runs before the release half.
• The test job moves into a reusable run_tests.yml that both ci.yml and the release gate call, on 8.0.x rather than the release workflow's 9.0.x, matching ci.yml and the net8.0 target. STREAM_API_KEY reads vars then secrets, because the two workflows disagreed about which held it and both exist.
• ci.yml drops its push trigger, which ran the suite twice per SHA and raced the live legs against the Stream app several SDK repos share. pr_title.yml is added to match the other SDKs.
• NuGet publishing keeps the OIDC login and dotnet nuget push --skip-duplicate, and workflow_dispatch takes publish_tag so an existing tag can be pushed after GitHub retires the original run.
• Deletes scripts/bump_version.sh, and backfills the changelog for 15.1.0 through 16.0.0.

How to verify

Dry-run against a throwaway branch carrying one fix: commit (release-please release-pr --dry-run --trace), now deleted:

• proposes 16.1.0 from base v16.0.0, which is the unreleased feat: from feat: [FEEDS-1763.1] regenerate OpenAPI client #74 finally shipping
• src/stream-feed-net.csproj <Version> 16.0.0 -> 16.1.0, and nothing else in the file moves
• CHANGELOG.md section inserted above ## [16.0.0]
• compare link v16.0.0...v16.1.0, so the tag shape is unchanged

actionlint clean on all four workflows. dotnet restore clean on the normalized csproj.

Expected on merge: a Release PR for 16.1.0, unlike the other four migrations. ci: is a hidden type, but #74's feat: is still unreleased on master, so there is a real release waiting.

Review instructions

The first Release PR's changelog will list [FEEDS-1763.1] regenerate OpenAPI client twice, once for the merge commit and once for the branch commit under it. That is history from before the repo went squash-only and it cannot be rewritten; later releases will not do it.

Merge settings are already correct: allow_merge_commit: false, allow_rebase_merge: false, squash_merge_commit_title: PR_TITLE, squash_merge_commit_message: BLANK.

One consequence worth agreeing on: master now has no routine CI. PR runs cover the merge ref, and the release gate covers the commit that gets tagged, but an ordinary merge to master runs nothing afterwards.

[mogita]

Reviewed at 8691da5. Two Must Fix, four Should Fix, all inline.

The two that matter: src/Client.cs loses its version bump, because no updater covers it once the script is gone, and the manifest seed is one release behind master after v16.0.1 landed today.

Nothing else blocks. The csproj change is whitespace-only with no dependency movement, run_tests.yml is a faithful move of the old ci.yml steps, the detect gating holds on every path I traced, and master has no required status checks, so the job renames break nothing.

Two smaller things left out of the inline comments: the packing SDK moves 9.0.x to 8.0.x (the TFM stays net8.0, but the toolchain producing the shipped nupkg changes), and run_tests.yml requires STREAM_API_KEY as a workflow_call secret while the steps read vars.STREAM_API_KEY || secrets.STREAM_API_KEY. Both exist today, so it works; retiring the secret in favour of the variable would fail the call at start-up.

[mogita]

Review addressed in e043484. Both must-fix and all four should-fix are fixed, replies on each thread.

Correcting the description, which is now wrong in the way the manifest comment describes: merging #77 fired the old release.yml, still on master and still triggering on a closed PR. It read fix(test): ..., cut v16.0.1, and shipped #74's feat: with it. So expected on merge is no Release PR, not a Release PR for 16.1.0, because the only commits this branch adds are ci: and docs:. The branch is rebased onto 9ce65bd and seeded at 16.0.1; a dry run with one fix: on top proposes 16.0.2.

On the two smaller notes:

Packing SDK 9.0.x to 8.0.x. Deliberate, and worth a second opinion. The TFM is net8.0, ci.yml has always used 8.0.x, and one reusable workflow cannot hold both, so the gate and the pack now agree on the version that matches the target. It does mean the shipped nupkg is produced by a different toolchain than 16.0.1 was. Say the word if you would rather both sides moved to 9.0.x instead.

STREAM_API_KEY declared required: true while the steps read vars first. Dropped to required: false in the same commit, so retiring the secret in favour of the variable no longer fails the call at start-up.