Automate widget installation and static verification

[mariojgt]

What changed

• Provision or safely adopt one site UUID on the first scan, persist its issuing endpoint atomically, and install one managed rolling-CDN widget in every required global source shell.
• Fail closed before posting for ambiguous/missing shells, external loaders, unsafe identity, and incomplete mixed Next App/Pages coverage.
• Add same-checkout provisioning serialization, atomic source/config/output writes, strict response validation, and retry-safe handling when source installation fails after the UUID is saved.
• Make mark-build --strict structurally stamp and verify complete static HTML, require explicit --static-output for SSR-capable stacks, and reject ambiguous populated output trees unless --dir is supplied.
• Add the maintained testConnect Vite fixture, generated/ignored source handling, field-test alignment, and expanded integration/unit coverage.

Why

The connector needs the UUID before compilation so the widget is visible immediately after installation and the same identity is baked into static production output. Previous manual instructions could miss the build lifecycle, duplicate widgets/sites, or report success without sitewide coverage.

Validation

• npm run typecheck
• npm test — 303 tests passed across 16 files
• npm run build
• testConnect: npm run fixture:reset-source && npm run build:static
• Field-test compliant stub — 8/8 checks passed
• git diff --check
• Branch started from current origin/main

Release gates

This is intentionally a draft. Do not publish the automatic embedding flow yet. The backend currently uses the client-visible UUID for manifest writes and unclaimed-site claiming, and bare provisioning still lacks a server-side idempotency key for timeout-after-commit recovery. The public widget identity, authenticated manifest-write credential, and scoped one-time claim credential must be separated and tested first. Coordinate the widget CDN release before the connector release, then deploy the matching website guides.

[coderbuds]

This PR is too large for detailed analysis—consider breaking it into smaller, focused changes.

🎯 oversized — strongly consider breaking this down

🛡️ Standards: no pre-flight fit check ran for this change — wire assess-change-fit into your coding agents to catch size before opening.

_{See how your team is trending →}