docs: add QUICKSTART.md — end-to-end CERTInext + Command setup

A 700-line "do this and you have working enrollment in 15 minutes"
guide for an operator with Command + Gateway already deployed and the
CERTInext plugin DLL on the gateway pod. Walks through:

  0. Variables (URLs, OIDC creds, CERTInext sandbox creds)
  1. OAuth tokens (gateway + Command, client_credentials)
  2. POST /AnyGatewayREST/config/certificateprofile per product
     (with the canonical key_algs payload to dodge 0xA0110004)
  3. POST/PUT /AnyGatewayREST/config/configuration
     (CAConnection + GatewayRegistration + Templates[])
  4. POST /KeyfactorAPI/CertificateAuthorities
     (Command CA registration with the KeyfactorSecret-wrapped client
     secret and the ConfigurationTenant convention)
  5. POST /KeyfactorAPI/Templates/Import
     (Command pulls AnyCA_<ProductID> templates from the gateway)
  6. POST /KeyfactorAPI/Enrollment/PFX
     (verification; expected outcome is RequestDisposition=
     EXTERNAL_VALIDATION, which the guide explains is success)

Each step is shown twice — Bash + curl and PowerShell + Invoke-
RestMethod — with the variables flowing forward across steps. Closes
with a Next Steps section (scaling to all 8 products, production
hardening, CSR alternative, sandbox burst-rate-limit caveat per #8)
and a Troubleshooting table mapping every failure mode encountered
during the kfclab integration to its fix.

Includes a "Data model & dependency order" preamble that explains why
certificateprofile creation precedes CA configuration (top-level
gateway resource vs. CA-config reference) — disambiguates "template"
between the gateway and Command sides where the term is overloaded.

Targeted at operators with Command + Gateway already deployed and the
plugin DLL staged. Helm install / Extensions/ wiring stays out of
scope and continues to live in the README.

Author: spbsoluble