fix: resolve #72

[Shaidyk]

Resolves #72.

Added a new ReplicationPlugin (plugins/replication/) that pulls data from the configured external data source (Postgres/MySQL/SQLite/Hyperdrive) into the internal Durable Object SQLite database, so a StarbaseDB instance can serve as a close-to-edge replica. Replication is pull-based and append-only: per table the user defines a tracking column (e.g. id or created_at), and each pull fetches only rows newer than the last checkpoint, which is persisted in a tmp_replication_checkpoints table.

/claim #72

[RudraMalvankar]

Nice work on the replication plugin! One question: how does this handle updates or deletes in the source database after a row has already been replicated? Since replication appears to be append-only, it seems those changes wouldn't propagate. Would it be worth mentioning this limitation more explicitly in the README so users know it's intended behavior?

[Shaidyk]

You're right that replication is append-only and pull-based, so in-place updates and deletes to already-replicated rows won't propagate — only new rows past the tracked trackBy value are fetched (though re-seeing a row's key would upsert via INSERT OR REPLACE). That's intended behavior for this first version, and I agree it's worth calling out explicitly; I'll add a note to the README's Notes section documenting the limitation.