schema.yaml: LQL support inside `functions[].body` (currently raw SQL only) [NAP Tier 1]

[MelbourneDeveloper]

DataProvider v0.9.8-beta closed #33 (declarative `CREATE FUNCTION`). The `body:` field on `functions[]` accepts raw SQL — that's the only place NAP still ships SQL through migration after the operator's "no loose SQL" mandate.

NAP request: allow LQL in `functions[].body` so the entire migration is portable. Today every NAP helper is forced to be SQL:

```yaml
functions:

• name: is_member
  arguments: [{name: u, type: uuid}, {name: t, type: uuid}]
  returns: boolean
  securityDefiner: true
  body: |
  SELECT EXISTS (
  SELECT 1 FROM public.tenant_members
  WHERE user_id = u AND tenant_id = t
  )
  ```

The same body in LQL (per the README's `exists(pipeline)` syntax used in policy predicates):

```yaml
functions:

• name: is_member
  arguments: [{name: u, type: uuid}, {name: t, type: uuid}]
  returns: boolean
  securityDefiner: true
  bodyLql: |
  exists(
  tenant_members
  |> filter(fn(m) => m.user_id = u and m.tenant_id = t)
  )
  ```

Acceptance criteria:

• New optional field (suggested name: `bodyLql:`) accepts LQL pipeline expressions plus simple `SELECT expr` shapes.
• Mutually exclusive with `body:`. Schema validator rejects both.
• Postgres transpilation emits the same SQL the existing LQL policy-predicate transpiler does (e.g. `SELECT EXISTS (SELECT 1 FROM public.tenant_members WHERE m.user_id = u AND m.tenant_id = t)`).
• SQLite transpilation deferred until SQLite RLS emulation needs it.

NAP Tier 1. Until this lands, NAP's `schema.yaml` ships 5 SECURITY DEFINER functions with raw SQL bodies — a violation of the operator's "every migration in YAML, no loose SQL" rule. `body:` (raw SQL) stays as the documented escape hatch for platform-specific stuff that LQL can't express, but the default path must be LQL.

Pairs with the GUC-reader gap: separate issue tracking the need for an LQL builtin to read arbitrary session settings (Postgres GUCs / SQLite context-table rows) so `app_tenant_id()` / `app_user_id()` can also be written in LQL.

[MelbourneDeveloper]

Bump — NAP Tier 1, still blocking.

NAP migrations/schema.yaml ships with 5 functions: entries whose body: is raw SQL because LQL function bodies aren't supported yet:

• app_tenant_id() — SELECT NULLIF(current_setting('app.tenant_id', true), '')::uuid
• app_user_id() — same shape, different GUC
• is_member(u uuid, t uuid) — SELECT EXISTS(SELECT 1 FROM tenant_members WHERE …)
• is_tenant_writer(u uuid, t uuid) — same, with role IN ('owner','admin')
• is_tenant_owner(u uuid, t uuid) — same, role = 'owner'

These are the ONLY raw SQL still in NAP's schema. AGENTS.md mandates 'MIGRATING THE STRUCTURAL DB SCHEMA WITH SQL IS ILLEGAL — NO SQL IN THE YAML FILE' and 'Always use LQL for RLS, functions etc.' We are knowingly violating our own rule until this lands.

Coupled with #44 — current_setting() is the only Postgres builtin all 5 functions need. Without #44, even an LQL body parser can't express what these functions do.

What would unblock NAP today: the 4 'EXISTS … FROM tenant_members WHERE …' bodies are pure SELECT predicates with parameter substitution — a straight subset of LQL's filter() expressions. Could you ship those FIRST as a v0.9.9-beta and let the 2 current_setting GUC-readers stay raw-SQL pending #44? That would close 4 of 5 raw-SQL escapes and leave 2 as a single dependency on #44.

[MelbourneDeveloper]

Fixed in the current workspace. PostgreSQL support functions now have bodyLql, it is mutually exclusive with raw body, schema YAML serializes/deserializes it, Postgres DDL emits SQL-language function bodies from LQL, and SchemaDiff treats inspected SQL bodies equivalent to their bodyLql source. Verification: focused PostgresFunctionBodyLqlTests + PostgresFunctionBodyLqlE2ETests passed, including NAP scalar current_setting bodies and EXISTS tenant_members function bodies; the full Migration test project also passed 487/487 with 0 skipped.