ci(publish): seed the DAR local feed from the release's own packages

[monsieurleberre]

Unblocks the 0.5.0-preview.1 release, and removes the cause of the same failure on the previous one.

The race

The DAR legs generate csprojs that reference Daml.Runtime and Daml.Ledger.Abstractions at the version this same workflow run pushed moments earlier, then resolve them from nuget.org.

nuget.org accepts a package immediately but does not serve it to restore until indexing completes. Right now, for 0.5.0-preview.1:

https://www.nuget.org/api/v2/package/Daml.Runtime/0.5.0-preview.1   -> 200
https://api.nuget.org/v3-flatcontainer/daml.runtime/…               -> 404

The package is downloadable and a real dotnet restore still fails:

NU1102: Unable to find package Daml.Runtime with version (>= 0.5.0-preview.1)
        - Found 13 version(s) in nuget.org [ Nearest version: 0.4.1-preview.1 ]

So the legs race an external queue whose latency is not ours to control.

Why losing it is fatal rather than slow

Every pack fails — including leaf packages with no sibling dependencies. On the 0.5.0-preview.1 tag that was all 33 Splice plus all 8 Daml.Finance packages, with 280 × NU1301 and zero NU1102:

NU1301: Failed to retrieve information about 'Daml.Runtime' from remote source
        'https://nuget.pkg.github.com/peacefulstudio/download/daml.runtime/index.json'
NU1301: Response status code does not indicate success: 401 (Unauthorized).

When nuget.org cannot answer, NuGet falls through to the github source, whose 401 is a hard error rather than a warning. On the previous release the same 401 appeared only as a warning, because resolution had already succeeded elsewhere.

The fix

local-feed already sits ahead of nuget.org in the generated NuGet.config (build-pack.sh:79-82) and already carries sibling DAR packages (build-pack.sh:112). It is simply never seeded with the core packages.

This seeds it from the nupkgs attached to the release being built, before build-pack.sh runs. Restores then resolve the exact bits that were published rather than whatever nuget.org is currently serving, and the indexing delay stops mattering. build-pack.sh only ever mkdir -ps that directory, so a pre-seeded feed survives.

Seeding is best-effort: a run whose release has no attached packages emits a warning and behaves exactly as it does today.

This also closes the sibling-resolution variant of the same race — the NU1102 failure on the previous release tag, which is this bug one level down.

Deliberately out of scope

Removing the unauthenticated github source. It contributes nothing here and converts lookup misses into hard failures, but it is a separate change and this one is wanted while a release is in flight.

Verification

Before merge this is a workflow-only change, so CI cannot exercise it. After merge, and before any real publish: a publish-splice.yaml dispatch with dry_run=true and both codegen_cs_version and runtime_version pinned to 0.5.0-preview.1 — the exact combination that fails today, with no push and no counter write-back.

[github-actions]

Scala coverage

Package	Line Rate	Branch Rate	Health
studio.peaceful.daml.codegen.helper	97%	96%	✔
Summary	97% (691 / 711)	96% (159 / 165)	✔

[github-actions]

C# coverage

Package	Line Rate	Branch Rate	Complexity	Health
Daml.Codegen.CSharp	97%	97%	1394	✔
Daml.Codegen.CSharp.Cli	100%	100%	3	✔
Daml.Codegen.Intermediate	100%	88%	30	✔
Daml.Codegen.Testing.Conformance	48%	47%	389	❌
Daml.Ledger.Abstractions	93%	94%	40	✔
Daml.Ledger.Abstractions.Testing.Conformance	77%	55%	22	✔
Daml.Runtime	94%	90%	877	✔
Summary	86% (5807 / 6722)	88% (2280 / 2588)	2755	✔

[github-actions]

Scala build matrix

shard	result	duration
macos-amd64	✅ success	1m 53s
macos-arm64	✅ success	1m 03s
ubuntu-amd64	✅ success	48s
ubuntu-arm64	✅ success	51s
windows-amd64	✅ success	1m 22s

[github-actions]

C# build matrix

shard	result	duration
macos-amd64	✅ success	2m 31s
macos-arm64	✅ success	1m 20s
ubuntu-amd64	✅ success	1m 26s
ubuntu-arm64	✅ success	1m 09s
windows-amd64	✅ success	1m 49s
windows-arm64	✅ success	1m 47s