Ship transaction-free bundles by default

[lemuelroberto]

Why

Release bundles carried one BEGIN;/COMMIT; pair per script section
(30 pairs in the all-in bundle). That makes them impossible to embed
where the caller already owns the transaction — a migration tool
(Kysely, Flyway, Liquibase…) runs each migration inside one, and the
bundle's first COMMIT; ended it halfway through. pgtle-wrap.sh
already worked around the same problem for CREATE EXTENSION by
grepping the lines out.

What changes

• sql/ carries no transaction control. The plain artifacts are what
  the sources say and run inside the caller's transaction (psql -1,
  a migration, CREATE EXTENSION).
• Every artifact gets a -tx twin with exactly one BEGIN; and
  one COMMIT; around the whole bundle, for a bare psql -f.
• pgtle-wrap.sh wraps the plain files unchanged and refuses input
  that controls transactions (e.g. a -tx file).
• build-release.sh refuses a BEGIN;/COMMIT; line in sql/; CI now
  runs it on every PR.
• The release smoke job installs each plain artifact between BEGIN
  and ROLLBACK and asserts no cel schema survives (a stray
  COMMIT; fails it), then installs it with --single-transaction,
  then installs the -tx twin with a bare psql -f.
• docs/INSTALL.md documents both shapes and a "Inside a migration
  tool" section. Version bumped to 0.0.2.

Verified locally

• docker compose up -d --wait + go vet ./... + go test ./...: ok.
• The smoke job script, extracted from release.yml: ok for
  cel4postgres and cel4postgres-core, both shapes. With a COMMIT;
  injected at top level of the plain bundle it fails with
  "committed on its own".
• The pg_tle job script for all and core ext_strings: ok.

Release

After merge, the 0.0.2 release is the manual Release workflow.
fga4postgres will vendor the published cel4postgres--0.0.2.sql.