Track release readiness for the real Payjoin C# NuGet package

[chavic]

This issue tracks the work required to replace the current placeholder Payjoin package with a real public C# NuGet release for payjoin-ffi/csharp. The bindings are functioning locally and tests pass after fresh generation, but the packaging and release path are still draft-grade: the current package model is not yet aligned with recommended .NET native packaging patterns, only ships whatever native artifact exists on the build machine, uses debug artifacts today, and has no CI-backed pack/install/publish flow.

Goals

• publish a real Payjoin NuGet package
• ship supported native assets for target platforms
• make package installation, build behavior, and runtime loading predictable for consumers
• make the release process reproducible in CI

Work Items

• Replace the current draft nuspec-based packaging approach with a release-ready package layout
• Stop relying on contentFiles + runtimes/any/native for the public package
• Decide the final package structure
• Define the supported RID matrix for the first real release
• Build per-RID native artifacts in CI
• Build release/optimized native artifacts instead of debug artifacts
• Add CI steps to:
  • generate bindings
  • build native assets
  • pack the NuGet package
  • install the package into a clean sample app
  • run smoke tests on each supported OS
• Document the release workflow, including versioning and publish steps
• Rewrite the package README for consumers with install instructions, prerequisites, minimal usage, and support matrix
• Clean up or explicitly accept generated-code warnings before release

Done When

This is done when CI can produce a release-grade Payjoin NuGet package that installs and runs correctly on every supported platform.

Open Questions

• What is the minimum supported platform/RID set for the first real release?
• Should the package ship generated source, a managed wrapper assembly, or both?
• Do we want an intermediate preview release before the first real stable release?

[DanGould]

• What is the minimum supported platform/RID set for the first real release?

Our current BTCPay is .NET 8.0 x86_64. Compile for there would mean we wouldn't complain. Does that answer fit the shape of this hole?

• Should the package ship generated source, a managed wrapper assembly, or both?

what are the trade offs?

• Do we want an intermediate preview release before the first real stable release?

before committing to a stable api definitely yes, our main api isn't even stable. Minor release seems the clear appropriate choice here