Ship installable paid-pilot release

[fly1d]

Closes #8

Outcome

Turns RabbitMQ Guard into an installable public v0.6.0 candidate and gives the RMB 1,999 / 14-day diagnostic service a bounded, privacy-conscious inbound path.

Changes

• package all 11 synthetic scenarios and workbench assets in wheel/sdist
• add rabbitmq-guard demo, --version, and installed-user data paths
• add Apache-2.0 licensing, package metadata, support boundaries, and release documentation
• add a public paid-pilot Issue Form that explicitly rejects customer data and credentials
• add Python 3.9/3.12 package builds and installed-wheel smoke tests to required CI
• add tag/main/version-gated GitHub Release automation with SHA-256 checksums and build provenance attestations

Risk

Medium/high. This adds a workflow with contents: write, id-token: write, and attestations: write, plus a public customer intake surface. The workflow runs only on version tags, requires the tag to match the runtime and built package version, and requires the tag commit to equal current origin/main. Checkout credentials are not persisted. The intake form gathers only customer-fit information and warns against names, internal identifiers, logs, snapshots, bundles, or credentials.

No customer data is added or processed by this change. All moved scenario files are byte-identical synthetic fixtures.

Verification

• make verify (44 tests, Python 3.9)
• make smoke
• make package-smoke
• Python 3.12: 44 tests plus installed-wheel and distribution checks
• wheel/sdist metadata and required contents checked
• installed workbench and packaged demo tested outside the checkout
• default and overridden installed database paths checked
• all repository YAML parsed
• browser JavaScript syntax checked
• sensitive credential-pattern scan returned no matches
• all 11 moved scenarios compared byte-for-byte with main
• version mismatch negative test rejects release artifacts

Rollback

Revert the squash commit before creating a release tag. After a release, publish a new patch version rather than moving or reusing the v0.6.0 tag.

[fly1d]

Code review completed against c8b7d76 after all required checks passed.

No blocking findings.

Reviewed specifically:

• Release permissions are limited to the tag-triggered job; checkout credentials are not persisted. The workflow rejects tags that do not match the runtime and built distribution version, and rejects tags not pointing to current origin/main.
• The wheel and sdist checks require all 11 synthetic scenarios, workbench assets, Apache-2.0 metadata, matching filenames, and consistent wheel/sdist metadata. Installed-package smoke runs outside the checkout on Python 3.9 and 3.12.
• The public paid-pilot form asks only for fit, problem category, access constraints, budget authority, and desired outcome. It repeatedly prohibits customer names, identifiers, logs, snapshots, bundles, and credentials.
• Installed database defaults remain local to the user's OS data directory, with an explicit environment override. Live collection remains loopback-only when enabled.
• All 11 scenario moves are 100% renames and were independently compared byte-for-byte with main.

Residual risk: this is the first execution of the tag-triggered Release workflow, so the v0.6.0 release must be verified after main CI succeeds. The release assets, SHA256SUMS, provenance attestation, installed wheel, license detection, and Issue Form should all be checked before treating the release as complete.