Summary

The README previously had a "Run the Orders sample" quickstart but no end-to-end tutorial for spinning up a brand-new service from scratch. This PR adds that tutorial alongside a release-publish workflow so the packages it tells readers to `dotnet add` actually resolve once the maintainer cuts a release.

README

"Build your first Firefly service" — new section right after the sample quickstart

Walks the reader from `dotnet new webapi` to a runnable hello-world service in six numbered steps:

1. Prerequisites — .NET 10 SDK, `curl`.
2. Create the project — `dotnet new webapi -n HelloFirefly`.
3. Install the framework — `dotnet add package FireflyFramework.Starter.Core`.
4. `Program.cs` — 40-line bootstrap showing `AddFireflyCore` + `UseFireflyWeb` + a minimal CQRS command/handler against the real `ICommand` / `ICommandHandler<TCommand, TResult>` interfaces.
5. `appsettings.json` — matching `Firefly:*` config snippet.
6. Smoke-test — `dotnet run` + curl exercising the happy path and the `X-Idempotency-Key` replay path.

Plus a follow-up checklist (add a query, promote to the canonical 5-project layout, pick a richer starter) and links to `docs/SERVICE-SCAFFOLDING.md` + `docs/CONFIGURATION.md`.

"Releases & publishing" — new section right after "Versioning"

Documents the CI / publish split, where packages land (NuGet.org + GitHub Packages + release assets), and how to cut a release (`git tag` + `gh release create` for the common path; `workflow_dispatch` for hotfix / pre-release cuts).

Workflows

`.github/workflows/ci.yml` — fix .NET version

Bumped `dotnet-version` from `9.0.x` to `10.0.x`. The projects target `net10.0`; the wrong runtime would have failed on a fresh runner. Pack job is unchanged: it uploads every `src/*` `.nupkg` as a workflow artifact for preview, but does not push to a registry.

`.github/workflows/publish.yml` — new

Triggers on a published GitHub Release (tag `vX.Y.Z` → package version `X.Y.Z`) or by manual `workflow_dispatch` with an explicit version. Steps:

1. Setup .NET 10.
2. Resolve version (release tag or manual input).
3. Restore + build + test.
4. `dotnet pack` with `-p:PackageVersion=$VERSION -p:Version=$VERSION -p:ContinuousIntegrationBuild=true` so symbol packages embed the right repo URL.
5. Upload `.nupkg` + `.snupkg` as a workflow artifact (audit trail).
6. Push to NuGet.org via `secrets.NUGET_API_KEY` — skipped with a warning if the secret isn't configured (useful for first-time setup).
7. Push to GitHub Packages via the workflow's `GITHUB_TOKEN` (always present, no extra setup).
8. Attach packages to the GitHub Release as downloadable assets (only on release events).

Both pushes use `--skip-duplicate`, so re-running on the same version is a safe no-op.

Verification

• `dotnet pack FireflyFramework.sln --configuration Release` packs 51 NuGet packages (52 `src/*` projects minus `FireflyFramework.ConfigServer`, which is an executable Web host with `false`). Sample projects and the test project carry the same opt-out.
• The CQRS interface signatures used in the tutorial (`ICommand`, `ICommandHandler<in TCommand, TResult>`, `HandleAsync(command, context, ct)`) match the real surface in `src/FireflyFramework.Cqrs/Commands/`.

Test plan

• `dotnet build FireflyFramework.sln` — 0 errors / 0 warnings
• `dotnet test FireflyFramework.sln --no-build` — 346 / 346 pass (unchanged)
• `dotnet pack FireflyFramework.sln --configuration Release` — 51 `.nupkg` produced; samples + tests + ConfigServer correctly excluded

Maintainer setup (one-time)

To enable NuGet.org publishing, configure a repository secret named `NUGET_API_KEY` at https://github.com/fireflyframework/fireflyframework-dotnet/settings/secrets/actions. Until then, the workflow only pushes to GitHub Packages and attaches `.nupkg` to the release.