Adds the Offerings module and retargets the CI/CD pipeline to Api.SlpSoftware

Implements Unit 2 "Offerings" (backend module, admin CRUD UI with
drag-and-drop reordering, public GET /api/v1/offerings endpoint) and
executes the feature's D-15 CI/CD cutover, switching the deploy
pipeline's build/publish target from SlpModularCms.Api to
SlpModularCms.Api.SlpSoftware.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN

aidlc-docs/features/slpsoftware-api/operations/plans/deployment-setup-plan.md

@@ -0,0 +1,59 @@
+# Deployment Setup Plan — slpsoftware-api (D-15 Cutover)
+
+## Investigation (Before Drafting Anything)
+
+Read `.gitea/workflows/continuous_integration.yaml`, `.gitea/workflows/deploy-scp.yaml`, and
+`gitea-deployment-workflow/operations/deployment/{deployment-instructions.md,rollback-plan.md}` in
+full before touching anything, per D-7's "extend, don't duplicate" instruction.
+
+- **`deploy-scp.yaml` needs zero changes.** It never hardcodes an entry-point `.dll` name anywhere —
+  it uploads whatever the publish artifact contains and restarts a `service_name` input (a plain
+  string). The cutover is invisible to this file.
+- **`continuous_integration.yaml` hardcodes `SlpModularCms.Api` in exactly 6 lines**, all inside
+  `publish-test`/`publish-production` (3 each): the "Build admin frontend" step's
+  `mkdir -p ../src/SlpModularCms.Api/wwwroot/admin` + `cp -r dist/. ../src/SlpModularCms.Api/wwwroot/admin/`,
+  and the "Publish" step's `working-directory: src/SlpModularCms.Api`. Every other `SlpModularCms.Api`
+  reference in the file is `SlpModularCms.Api.Tests` (the `backend-test` job) — Unit 1's own pipeline
+  regression suite, deliberately scoped to `Api` only (NFR-CS-01), and correctly untouched here: `Api`
+  keeps existing as the local dev host (D-8), so its own regression tests still make sense to run.
+- **`deployment-instructions.md` § 1.6**'s systemd unit `ExecStart` lines reference
+  `SlpModularCms.Api.dll` explicitly — this is **host configuration**, per the doc's own framing
+  ("everything here is host configuration the workflow assumes already exists — `deploy-scp.yaml`
+  never creates any of it"). Updating the *documented* command is this feature's job; applying it to
+  the *actual, already-running* systemd units on the Pi is the user's own manual step, same as every
+  other host-side item in that document — this session has no access to the Pi.
+- **No nginx changes** (D-6, already decided) — the proxy Pi's server blocks point at pi-main's port,
+  not at a specific executable; whichever `.dll` is running behind that port is invisible to nginx.
+- **No database change** — same customer/instance, same domain, same `DB_NAME` (`SlpSoftware<Env>`);
+  the cutover only changes which project's compiled output the existing systemd units execute.
+- **No Gitea Actions variables/secrets change** — `DEPLOY_PATH_*`, `SERVICE_NAME_*`,
+  `HEALTH_CHECK_URL_*`, and every other `vars.*`/`secrets.*` already describe the *target* (paths,
+  service names, domains), none of which change in a same-host, same-service-name cutover.
+- **`rollback-plan.md` needs zero changes** — it operates entirely at the release-directory/symlink
+  level (`current` → `releases/<timestamp>`), never referencing a specific `.dll` name.
+
+## Why No Questions This Time
+
+Every decision this stage would normally ask about is already made and traced in `requirements.md`:
+D-6 (no nginx change), D-7 (extend the existing pipeline, don't fork it), D-8 (`Api` stays as local
+dev host, unaffected), D-15 (this is a cutover, not side-by-side). This stage is mechanical execution
+of already-approved decisions, not new design — flagging that explicitly rather than manufacturing a
+question with no real alternative to weigh.
+
+## Checklist
+
+- [x] Update `continuous_integration.yaml`: `SlpModularCms.Api` → `SlpModularCms.Api.SlpSoftware` in
+      the 6 identified lines (3 in `publish-test`, 3 in `publish-production`) — nowhere else
+- [x] Update `gitea-deployment-workflow/operations/deployment/deployment-instructions.md` § 1.6:
+      systemd unit `ExecStart` lines → `SlpModularCms.Api.SlpSoftware.dll`, with an explicit note
+      that this is a **cutover the user must apply by hand** to the Pi's already-existing
+      `slpsoftware-test.service`/`slpsoftware-production.service` unit files (this session cannot
+      reach the Pi) — directly answering the user's earlier question about whether those two unit
+      files need editing
+- [x] Create `aidlc-docs/features/slpsoftware-api/operations/deployment/deployment-instructions.md`
+      as a short feature-local pointer document: this feature does not own a separate deployment
+      pipeline, it extends `gitea-deployment-workflow`'s — record that relationship plus exactly what
+      changed and why, rather than duplicating the full instructions
+- [x] Verify no other file in the repo hardcodes `SlpModularCms.Api` in a way that's actually about
+      *this pipeline's deploy target* (as opposed to `Api`'s own continued existence as local dev
+      host, or `Api.Tests`, both of which are correctly unaffected)