docs: update all documentation for v1.0.0 release

- Fix demo certificate count: 14 → 15 across README, quickstart,
  demo-guide (wildcard cert was added but count never updated)
- Fix negative_test subtest count: 12 → 14 in architecture.md
- Update README roadmap: v1.0.0 released (no longer "tag pending")
- Update status badge: "active development" → "v1.0.0"
- Remove stale POSTGRES_IMPLEMENTATION.md and POSTGRES_PATTERNS.md
  (scaffold-era dev notes, not referenced anywhere)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/architecture.md

@@ -585,7 +585,7 @@ certctl uses a layered testing approach aligned with the handler → service →
 
 **Handler layer tests** (`internal/api/handler/*_test.go`) — 127 test functions across 7 files using Go's `httptest` package. Every handler file has a corresponding test file: certificates (22 tests), agents (28 tests), jobs (13 tests), notifications (11 tests), policies (19 tests), issuers (17 tests), and targets (17 tests). Each test file follows the same pattern: a mock service struct with function fields, `httptest.NewRecorder` for capturing responses, and a shared `contextWithRequestID()` helper. Tests cover the happy path, input validation (missing fields, invalid JSON, empty IDs), error propagation from the service layer, method-not-allowed responses, and pagination parameters.
 
-**Integration tests** (`internal/integration/`) — Two test files exercising the full stack from HTTP request through router, handler, service, and postgres repository layers. `lifecycle_test.go` has 11 subtests covering the complete certificate lifecycle: team/owner creation, certificate creation, issuer verification, renewal trigger, job verification, agent registration, CSR submission, deployment, and status reporting. `negative_test.go` has 12 subtests covering error paths: nonexistent resource lookups (404s), invalid request bodies (malformed JSON, missing required fields), invalid CSR submission, heartbeat for nonexistent agents, wrong HTTP methods on list endpoints, empty list responses, renewal on nonexistent certificates, and expired certificate lifecycle. Both use a shared `setupTestServer()` that builds a fully-wired server with real postgres repositories and the Local CA issuer connector.
+**Integration tests** (`internal/integration/`) — Two test files exercising the full stack from HTTP request through router, handler, service, and postgres repository layers. `lifecycle_test.go` has 11 subtests covering the complete certificate lifecycle: team/owner creation, certificate creation, issuer verification, renewal trigger, job verification, agent registration, CSR submission, deployment, and status reporting. `negative_test.go` has 14 subtests covering error paths: nonexistent resource lookups (404s), invalid request bodies (malformed JSON, missing required fields), invalid CSR submission, heartbeat for nonexistent agents, wrong HTTP methods on list endpoints, empty list responses, renewal on nonexistent certificates, and expired certificate lifecycle. Both use a shared `setupTestServer()` that builds a fully-wired server with real postgres repositories and the Local CA issuer connector.
 
 **Frontend tests** (`web/src/api/client.test.ts`, `web/src/api/utils.test.ts`) — 53 Vitest tests covering the API client and utility functions. The API client tests mock `globalThis.fetch` and verify all endpoint functions (certificates, agents, jobs, policies, issuers, targets, notifications, audit, health) send correct HTTP methods, URLs, headers, and request bodies. They also test API key management (store/retrieve/clear), auth header propagation, 401 event dispatching, and error handling (server messages, error fields, status text fallback). The utility tests use `vi.useFakeTimers()` for deterministic date testing and cover `formatDate`, `formatDateTime`, `timeAgo`, `daysUntil`, and `expiryColor`. The test environment uses jsdom with `@testing-library/jest-dom` matchers.
 

docs/demo-guide.md

@@ -16,7 +16,7 @@ Wait ~30 seconds for PostgreSQL to initialize and the server to start, then open
 
 **http://localhost:8443**
 
-You'll see the dashboard pre-loaded with 14 demo certificates across multiple teams, environments, and statuses — including expiring, expired, active, failed, and in-progress renewals.
+You'll see the dashboard pre-loaded with 15 demo certificates across multiple teams, environments, and statuses — including expiring, expired, active, failed, wildcard, and in-progress renewals.
 
 ## What You'll See
 

docs/quickstart.md

@@ -58,7 +58,7 @@ curl http://localhost:8443/health
 
 Open **http://localhost:8443** in your browser.
 
-The dashboard comes pre-loaded with 14 demo certificates across multiple teams, environments, and statuses. You'll see expiring certs, expired certs, active certs, failed renewals — a realistic snapshot of what a certificate inventory looks like in a real organization.
+The dashboard comes pre-loaded with 15 demo certificates across multiple teams, environments, and statuses. You'll see expiring certs, expired certs, active certs, failed renewals — a realistic snapshot of what a certificate inventory looks like in a real organization.
 
 Explore the sidebar: Certificates, Agents, Policies, Jobs, Audit Trail, Notifications. Everything you see in the dashboard is backed by the REST API.
 
@@ -92,7 +92,7 @@ The response has this shape:
       "updated_at": "2026-03-14T00:00:00Z"
     }
   ],
-  "total": 14,
+  "total": 15,
   "page": 1,
   "per_page": 50
 }
@@ -217,7 +217,7 @@ The demo comes pre-loaded with realistic data so you can explore certctl's featu
 | Issuers | 3 | Local Dev CA, Let's Encrypt Staging, DigiCert |
 | Agents | 5 | nginx-prod, nginx-staging, f5-prod, iis-prod, data-agent |
 | Targets | 5 | NGINX (prod/staging/data), F5 LB, IIS |
-| Certificates | 14 | Various statuses: Active, Expiring, Expired, Failed |
+| Certificates | 15 | Various statuses: Active, Expiring, Expired, Failed, Wildcard |
 | Policies | 4 | Required owner, allowed environments, max lifetime, min renewal window |
 
 Certificates have varied statuses so you can see what each state looks like in the dashboard: healthy certs with 45+ days remaining, certs about to expire (5-12 days), certs that already expired, and a failed renewal.