Single-commit fast path for application tables in the system database

[SamuelXing]

Closes #155, follow-up to #153.

If your app tables live in the same database as the dbos schema, the two-commit protocol is wasted work — one commit could cover the writes and the checkpoint together. The catch: the SDK can't safely detect that a user-built datasource points at the system DB (sqlx pools have no identity comparison, and a wrong guess would break atomicity).

So instead of detecting, the provider hands it out: provider.system_datasource() builds a datasource from its own pool, so sameness is true by construction. transaction_on sees the flag and takes a single-commit fast path — body and checkpoint in one transaction, no witness table, no crash window.

Why it matters: same-DB users used to choose between ctx.transaction (one commit, but only Param's six types) and a manual datasource (native connection, but two commits). Now they get the native connection — jsonb, arrays, uuid, existing sqlx code — at one commit.

Notes:

• PgDataSource::new never takes the fast path, even if pointed at the system DB. The flag is crate-private; only the provider can set it, so it can't be wrong.
• Failures record as ordinary step failures; the raw-COMMIT guard and retry behavior carry over unchanged.
• Docs: a "which transaction API?" decision table, a trust note (the connection is unrestricted — the app owns the database), and the search_path caveat for unqualified DDL.

Tests: sqlite single-commit + no witness table + exactly-once replay; failure rollback and error replay; hermetic Postgres binding jsonb and bigint[] natively.