M3 plugin platform: SDK + loader, RLS-isolated tables, migrations, jobs

Backend foundation for the plugin platform (SPEC §11), Phases 1-3.

Phase 1 — SDK + loader:
- app/plugins/types.py: frozen Plugin/UiManifest/Slot/Page/JobSpec contract.
- app/plugins/sdk.py: sdk(name) facade — the only app.* import allowed for plugins
  (scoped session, plugin.{name}.* publish, blob, outbox, settings, SSRF http_get, KV, enqueue).
- app/plugins/loader.py: entry-point discovery (webmail.plugins), hook forwarding
  (API + worker), router mounting at /api/plugins/{name}, ui-manifest aggregation.
- plugin_kv core table (migration 0013) + GET /api/plugins/ui-manifest.

Phase 2 — non-removable core plugins + DB-enforced privacy:
- builtin flag (calendar/contacts will be builtin=True; uninstall refuses them).
- RLS per-user isolation on plg_* tables: least-privilege webmail_plugin role
  (migration 0014), plugin_session(user_id) sets LOCAL ROLE + app.current_user_id,
  rls.enable_rls() (ENABLE+FORCE RLS + USING/WITH CHECK policy). Mail untouched.
- Per-plugin Alembic runner (shared env, dedicated version table) + install/uninstall
  --drop-data CLI; skeleton fixture proves install -> run -> uninstall --drop-data
  leaves zero residue (§12 M3 acceptance).

Phase 3 — plugin jobs (§11.2):
- JobSpec registered as arq function plg.{plugin}.{func} + cron (5-field parser);
  singleton=True guarded by a per-(plugin,user) Redis lock; wired onto the shared
  interactive worker.

Gates: ruff, mypy --strict (94 files + tests), full suite 326 passed. RLS isolation,
migration round-trip, and singleton lock covered by tests.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rcj3TpydMTzTSmU7kunzf8

backend/app/plugins/rls.py

@@ -0,0 +1,46 @@
+"""Row-Level Security for plugin-owned tables (SPEC §11.1 + privacy hardening).
+
+Per-user isolation for ``plg_*`` tables is enforced by Postgres, not by remembering
+a ``WHERE user_id = ?`` in every query. Each user-data table gets RLS enabled +
+forced, with a policy comparing ``user_id`` to the transaction-local GUC
+``app.current_user_id``. Plugin code reaches these tables only through
+``sdk.session(user_id)`` (see :mod:`app.plugins.db`), which drops to the
+least-privilege :data:`PLUGIN_ROLE` and binds that GUC — so even a query that
+forgets to filter cannot see or write another user's rows.
+
+Plugin migrations call :func:`enable_rls` right after creating a user-data table.
+"""
+
+from __future__ import annotations
+
+# NOLOGIN, non-superuser, NOBYPASSRLS role plugin sessions SET LOCAL ROLE into
+# (created by core migration 0014). RLS is skipped for superusers / table owners /
+# BYPASSRLS roles, so plugin access must run as this restricted role to be enforced.
+PLUGIN_ROLE = "webmail_plugin"
+
+_USER_CTX = "current_setting('app.current_user_id', true)::uuid"
+
+
+def rls_ddl(table: str, *, user_column: str = "user_id") -> list[str]:
+    """SQL statements that lock ``table`` to the current user (SPEC §11.1).
+
+    Pure/testable: returns the DDL rather than executing it. ``FORCE`` makes even
+    the table owner subject to the policy; ``WITH CHECK`` blocks inserting/updating
+    rows for a different user."""
+    policy = f"{table}_user_isolation"
+    return [
+        f"ALTER TABLE {table} ENABLE ROW LEVEL SECURITY",
+        f"ALTER TABLE {table} FORCE ROW LEVEL SECURITY",
+        f"CREATE POLICY {policy} ON {table} "
+        f"USING ({user_column} = {_USER_CTX}) "
+        f"WITH CHECK ({user_column} = {_USER_CTX})",
+        f"GRANT SELECT, INSERT, UPDATE, DELETE ON {table} TO {PLUGIN_ROLE}",
+    ]
+
+
+def enable_rls(table: str, *, user_column: str = "user_id") -> None:
+    """Apply :func:`rls_ddl` via Alembic ``op`` — call from a plugin migration."""
+    from alembic import op
+
+    for statement in rls_ddl(table, user_column=user_column):
+        op.execute(statement)