LQL: `current_setting('namespace.key')` builtin for arbitrary session context (not just `current_user_id()`) [NAP Tier 1]

[MelbourneDeveloper]

LQL today exposes a single fixed session reader: `current_user_id()`, which expands to `current_setting('rls.current_user_id', true)` on Postgres and a row from the `__rls_context` table on SQLite (per Migration/README.md).

NAP needs two distinct session-scoped values: `app.tenant_id` and `app.user_id`. Both are set per-transaction via `SET LOCAL app.tenant_id = '...'` and consumed by RLS policies through helper functions:

• `app_tenant_id() RETURNS uuid` → `SELECT NULLIF(current_setting('app.tenant_id', true), '')::uuid`
• `app_user_id() RETURNS uuid` → same shape against `app.user_id`

These two helpers are the only reason NAP needs SQL function bodies at all. Every other function (`is_member`, `is_tenant_writer`, `is_tenant_owner`) is just an EXISTS check that LQL's `exists(pipeline)` already expresses cleanly — once #(LQL function body issue) lands and once those bodies can call a portable session-reader builtin.

NAP request: add a generic LQL builtin that accepts a session-context key:

```yaml
functions:

• name: app_tenant_id
  returns: uuid
  bodyLql: current_setting('app.tenant_id')::uuid
• name: app_user_id
  returns: uuid
  bodyLql: current_setting('app.user_id')::uuid
  ```

Postgres transpiles to `current_setting('app.tenant_id', true)::uuid` (the `true` flag ⇒ NULL when missing instead of erroring). SQLite transpiles to a lookup against the `__rls_context` table — the namespace+key pair becomes the row id.

Acceptance:

• LQL function: `current_setting()` → returns text, callable from `bodyLql:` and from policy `using:` / `withCheck:` predicates.
• Postgres emission: `current_setting('namespace.key', true)` (always missing-OK; NULL on absence).
• Cast support: composes with the existing LQL cast operator (`::uuid`, etc.) so callers can express `current_setting('app.tenant_id')::uuid` directly.
• SQLite emission deferred until SQLite RLS emulation needs it.

NAP Tier 1 alongside the LQL-function-body issue. Together they let NAP delete the last raw SQL from `migrations/schema.yaml`.

[MelbourneDeveloper]

Bump — NAP Tier 1, still blocking #43 unblock.

current_setting('namespace.key', missing_ok) is the Postgres mechanism for per-transaction context propagation that RLS policies depend on. NAP uses two GUCs — app.tenant_id and app.user_id — set by the API layer via SET LOCAL app.tenant_id = … before every tenant-scoped query, then read in policies and SECURITY DEFINER helpers via current_setting('app.tenant_id', true)::uuid.

Without an LQL builtin, every NAP RLS predicate or helper that consumes a GUC must be raw SQL. That is app_tenant_id(), app_user_id(), and any RLS using: predicate that compares a column to the GUC.

NAP shape we'd accept (most permissive first):

using: 'tenant_id = current_setting("app.tenant_id")::uuid'

Or the LQL-native form:

filter(row -> row.tenant_id == current_setting("app.tenant_id", missing_ok=true)::uuid)

This unblocks #43 partially (2 of 5 NAP functions become trivial one-liners) and removes the last raw-SQL escape from policies[].using:. PR-friendly: the implementation is a single LQL function-call AST node + current_setting(text, bool) Postgres binding, no schema changes.

[MelbourneDeveloper]

Fixed in the current workspace. LQL current_setting('<namespace.key>') is rewritten for PostgreSQL to current_setting('<namespace.key>', true), preserves casts such as ::uuid, works inside policy usingLql/withCheckLql and bodyLql, and rejects unsupported SQLite/non-literal forms. Verification: focused RlsCurrentSettingLqlTests and PostgresFunctionBodyLqlTests passed, including NAP tenant/user GUC shapes and EXISTS pipeline rewrites; the full Migration test project also passed 487/487 with 0 skipped.