feat(mysql): initial stable release v0.9.0

database/sql-backed MySQL client with launcher lifecycle, health check, unit-of-work via context injection, and structured error mapping.

What's included:
- Executor / Tx / Client / Component interfaces using database/sql native types (sql.Result, *sql.Rows, *sql.Row)
- Tx.Commit() / Tx.Rollback() without ctx, matching the honest database/sql contract
- New(logger, cfg) constructor; *sql.DB opened in OnInit
- Config struct with env-tag support for all pool tuning parameters
- UnitOfWork via context injection; GetExecutor(ctx) returns active *sql.Tx or *sql.DB
- HandleError mapping MySQLError.Number to xerrors codes (1062 → AlreadyExists, 1216/1217/1451/1452 → InvalidInput, ErrNoRows → NotFound)
- Driver imported as mysqldrv alias to avoid package name collision
- health.Checkable at LevelCritical; HealthCheck delegates to db.PingContext

Tested-via: todo-api POC integration
Reviewed-against: docs/adr/

docs/adr/ADR-001-database-sql-native-types.md

@@ -0,0 +1,37 @@
+# ADR-001: database/sql Native Types
+
+**Status:** Accepted
+**Date:** 2026-03-18
+
+## Context
+
+Go's standard `database/sql` package was designed as a database-agnostic abstraction. Using it for MySQL is the conventional approach: the `go-sql-driver/mysql` package registers itself as a `database/sql` driver, and all query operations are expressed through `*sql.DB`, `*sql.Tx`, `*sql.Rows`, `*sql.Row`, and `sql.Result`.
+
+An alternative would be to use a MySQL-specific client library analogous to pgx for PostgreSQL. However, there is no dominant MySQL-specific client with the same level of ecosystem adoption and capability that pgx has for PostgreSQL. Using `database/sql` with a standard driver is the practical and broadly understood choice.
+
+The `postgres` module deliberately chose pgx native types. MySQL is the counterpart — it uses `database/sql` native types. The two modules are not interchangeable, which is by design.
+
+## Decision
+
+The `mysql` module's `Executor` interface uses `database/sql` types throughout:
+
+```go
+type Executor interface {
+    ExecContext(ctx context.Context, query string, args ...any) (sql.Result, error)
+    QueryContext(ctx context.Context, query string, args ...any) (*sql.Rows, error)
+    QueryRowContext(ctx context.Context, query string, args ...any) *sql.Row
+}
+```
+
+Method names follow the `database/sql` convention (`ExecContext`, `QueryContext`, `QueryRowContext`) rather than the pgx convention (`Exec`, `Query`, `QueryRow`). This matches the underlying `*sql.DB` and `*sql.Tx` method signatures exactly, meaning `*sql.DB` satisfies `Executor` structurally without any wrapping.
+
+The `mysqlComponent` embeds `*sql.DB` and delegates directly. `mysqlTx` wraps `*sql.Tx` and delegates to it.
+
+## Consequences
+
+- **Positive**: Familiarity — `database/sql` is Go's standard library API, known to most Go developers.
+- **Positive**: `*sql.DB` and `*sql.Tx` natively satisfy the `Executor` interface, reducing the need for wrapper code.
+- **Positive**: Any `database/sql`-compatible driver (MariaDB, TiDB, etc.) could be substituted by changing the driver registration without touching the interface.
+- **Negative**: `sql.Result` is less informative than `pgconn.CommandTag` (no command string, only `LastInsertId` and `RowsAffected`). Applications that need PostgreSQL-style command metadata must use the `postgres` module.
+- **Negative**: `*sql.Rows` must be closed after use (`defer rows.Close()`). Forgetting this leaks connections back to the pool.
+- **Note**: The method naming difference from `postgres` (`ExecContext` vs `Exec`) is intentional and honest — it matches the actual API of the underlying library rather than artificially unifying the two modules.

docs/adr/ADR-002-no-ctx-on-tx-commit-rollback.md

@@ -0,0 +1,42 @@
+# ADR-002: No Context on Tx.Commit and Tx.Rollback
+
+**Status:** Accepted
+**Date:** 2026-03-18
+
+## Context
+
+The `postgres` module's `Tx` interface defines `Commit(ctx context.Context) error` and `Rollback(ctx context.Context) error` because `pgx.Tx` supports context-aware commit and rollback — the operation can be cancelled if the context is already done.
+
+The `database/sql` standard library's `*sql.Tx` does not support this. Its `Commit()` and `Rollback()` methods have no context parameter:
+
+```go
+// from database/sql:
+func (tx *Tx) Commit() error
+func (tx *Tx) Rollback() error
+```
+
+Adding a `ctx` parameter to the `mysql.Tx` interface would be a lie: the implementation would have to ignore the context, potentially masking cancellations or deadlines that callers believe they are enforcing.
+
+## Decision
+
+The `mysql.Tx` interface is defined with context-free commit and rollback, matching the `database/sql` contract honestly:
+
+```go
+type Tx interface {
+    Executor
+    Commit() error
+    Rollback() error
+}
+```
+
+The `UnitOfWork.Do` implementation calls `tx.Rollback()` and `tx.Commit()` without passing a context. This is consistent with the interface definition and with `database/sql` semantics.
+
+This means `mysql.Tx` and `postgres.Tx` are not structurally compatible — this is intentional. Callers must not attempt to use one in place of the other.
+
+## Consequences
+
+- **Positive**: The interface is an honest representation of what `database/sql` provides. No silent context-ignore bugs.
+- **Positive**: `mysqlTx.Commit()` and `mysqlTx.Rollback()` delegate directly to `*sql.Tx.Commit()` and `*sql.Tx.Rollback()` with no wrapper complexity.
+- **Negative**: A commit or rollback cannot be cancelled mid-flight via context in MySQL. If the database is slow or unreachable during commit, the goroutine blocks until the driver-level timeout fires.
+- **Negative**: The API asymmetry between `mysql.Tx` and `postgres.Tx` means that generic code written against one cannot be used against the other. This is a known limitation of the design and the reason the two modules are separate.
+- **Note**: Go 1.15 added `*sql.Tx.Commit()` and `*sql.Tx.Rollback()` that honour the context passed to `BeginTx` — but still do not accept a per-call context. The limitation is inherent to `database/sql`.

docs/adr/ADR-003-driver-alias-name-collision.md

@@ -0,0 +1,47 @@
+# ADR-003: Driver Import Alias to Avoid Name Collision
+
+**Status:** Accepted
+**Date:** 2026-03-18
+
+## Context
+
+The `errors.go` file in the `mysql` package uses the `go-sql-driver/mysql` package to type-assert MySQL error values:
+
+```go
+import "github.com/go-sql-driver/mysql"
+```
+
+The Go package name of `github.com/go-sql-driver/mysql` is also `mysql` — the same as the package being authored. This creates an ambiguous identifier: within `errors.go`, unqualified references to `mysql` would be interpreted as the current package, and the driver's `MySQLError` type would be inaccessible without a disambiguating qualifier.
+
+## Decision
+
+The driver is imported under the alias `mysqldrv`:
+
+```go
+import mysqldrv "github.com/go-sql-driver/mysql"
+```
+
+In `mysql.go`, the driver is imported for its side effect only (registering itself with `database/sql`) using the blank identifier:
+
+```go
+import _ "github.com/go-sql-driver/mysql" // register driver
+```
+
+The alias `mysqldrv` is used exclusively in `errors.go`, where `MySQLError` must be referenced by name for type assertion via `errors.As`:
+
+```go
+var mysqlErr *mysqldrv.MySQLError
+if errors.As(err, &mysqlErr) {
+    switch mysqlErr.Number { ... }
+}
+```
+
+The alias is chosen to be recognisable — `drv` is a conventional abbreviation for "driver" — while making the boundary between package code and driver code immediately apparent at each call site.
+
+## Consequences
+
+- **Positive**: No ambiguity between the `mysql` package and the `mysql` driver. The alias makes the distinction explicit at every use site.
+- **Positive**: The blank import in `mysql.go` documents clearly that the driver is needed only for side-effect registration.
+- **Positive**: If the driver package is ever replaced (e.g., with a fork or an alternative driver), only the import alias and the `mysqlErr.Number` switch need to change — the rest of the package is unaffected.
+- **Negative**: Readers unfamiliar with the convention must understand that `mysqldrv.MySQLError` refers to the external driver, not the current package. The alias name and the import comment mitigate this.
+- **Note**: Error number constants (1062, 1216, 1217, 1451, 1452) are not exported by `go-sql-driver/mysql`, so they are used as integer literals with inline comments identifying the MySQL error name (e.g., `// ER_DUP_ENTRY`).