feat(serve): add synchronous local-path scan API baseline

[mstykow]

Summary

• add a real provenant serve subcommand with a lightweight long-lived HTTP shell, health/readiness/version endpoints, and a working synchronous POST /v1/scans route
• add an evergreen docs/SERVE_API_GUIDE.md that documents the current HTTP surface directly, including curl examples, operator-mode path usage, and current limits
• add an implementation-coupled generated OpenAPI document at docs/openapi/provenant-serve.openapi.json plus an xtask generator and CI check to keep it in sync with the code

Issues

• Covers: Create provenant serve API #834

Scope and exclusions

• Included:
  • provenant serve --bind <HOST:PORT> CLI surface
  • long-lived service shell lifecycle and bind failure handling
  • GET /livez, GET /readyz, GET /version
  • synchronous POST /v1/scans
  • local-path sync request handling on top of the shared workflow/app pipeline
  • evergreen Serve API Guide for the current implemented baseline
  • generated OpenAPI artifact and xtask/CI verification
  • top-level integration tests, manual local e2e validation, and CI smoke coverage for the new command
• Explicit exclusions:
  • async scan endpoints and job persistence
  • repository inputs, upload inputs, and remote URL inputs
  • auth and broader hosted-service/platform concerns
  • closing Create provenant serve API #834 end-to-end

Intentional differences from Python

• introduce a Provenant-specific long-lived service command and synchronous HTTP scan API; this is not a ScanCode CLI parity surface

Follow-up work

• Created or intentionally deferred:
  • async routes such as POST /v1/scans:async and /v1/jobs/... remain defined in the end-state plan but are not implemented in this PR
  • the end-state contract in docs/implementation-plans/infrastructure/SERVE_PLAN.md now prioritizes repository inputs, upload inputs, remote URL inputs, and automation-friendly async jobs beyond this path-based baseline
  • Create provenant serve API #834 stays open until the broader serve contract is implemented beyond the synchronous local-path slice

Expected-output fixture changes

• Files changed: none
• Why the new expected output is correct: this PR adds a new service transport plus user-facing HTTP documentation/spec artifacts, but does not change existing golden fixture outputs