feat: generate splinter.json manifest and publish via release workflow

[soedirgo]

What

Emit a structured splinter.json manifest alongside splinter.sql, and add a release workflow that publishes it to GitHub Releases + S3.

splinter.sql is a single monolithic union all query. Consumers that want to select/filter/combine individual lints (e.g. supabase/platform's advisor) currently reverse-engineer structure out of that blob with a paren-depth scanner and regexes — fragile, and it fails silently against live customer DBs when the SQL shape changes. The manifest exposes that structure as data instead.

Shape

{
  "version": "<CalVer YYYY.MM.Micro>",
  "setup": "set local search_path = '';\n\ndo $$ ... $$;",
  "lints": [ { "name": "...", "categories": ["SECURITY"], "query": "(select ...)" } ]
}

• query is the same union-ready parenthesized SQL that splinter.sql uses — consumers treat it as opaque.
• name / categories are lifted from each lint's SQL at build time, so a malformed lint fails CI rather than a consumer's regex failing silently later.
• setup is the existing header (search_path='' + the do $$ block), run once before the union.

Changes

• bin/compile.py — refactored into importable compile_sql() / main() under a __main__ guard. splinter.sql output is byte-identical (verified: empty diff).
• bin/compile_json.py (new) — the manifest generator. Reuses compile.load_sql_files.
• .github/workflows/release.yml (new) — on push to main:
  • Release only when there's a release-worthy Conventional Commit since the last tag: feat:, fix:, or any breaking change (type!:, or a BREAKING CHANGE: / BREAKING-CHANGE: footer). chore/docs/refactor/test/ci/perf do not trigger a release.
  • Compute YYYY.MM.Micro (micro = next counter for the current month). All release-worthy commits bump the single micro equally — no feat→minor / fix→patch distinction in CalVer.
  • Create the tag + GitHub release with splinter.json.
  • Publish to s3://<shared-services-bucket>/splinter/<calver>/splinter.json via OIDC role-chaining (mirrors the supautils release).
• .gitignore — splinter.json is generated/published, never committed.

⚠️ Prerequisites for the S3 upload

• IAM role granting this repo PutObject under splinter/*: supabase/platform#36435 (must be deployed first).
• Repo secrets SHARED_SERVICES_OIDC, SHARED_SERVICES_ROLE (= the new role's ARN), SHARED_SERVICES_BUCKET must be set.
• The OIDC jump role already trusts repo:supabase/*, so no OIDC-provider change is needed.

Consumer side

supabase/platform#36414 — advisor consumes this manifest instead of scraping splinter.sql.

🤖 Generated with Claude Code