fix: order a table after the functions its policies call

[dilame]

What changed

A table is now ordered after the functions its RLS policies call.

• GetPolicies returns the policy's oid.
• Policy gains DependsOnFunctions, read from pg_depend (pg_policy → pg_proc), the same way a check constraint's function dependencies are read.
• The table generator adds the edges: a table's add/alter runs after those functions, and its drop runs before their drop.

The edges belong on the table's vertex, not the policy's. A table's policies are emitted inside the table's own statement list — inside CREATE TABLE for a new table, appended by the table's alter otherwise — so a policy never has a vertex of its own in the top-level graph, and an edge from it would resolve against nothing.

Why

PostgreSQL resolves the functions named in a policy expression at CREATE POLICY time. Nothing ordered a policy against them, so a plan that creates a function and a policy calling it could emit the policy first and fail:

CREATE POLICY "app_sel_own_partner" ON "affiliate"."campaign" ...
USING ((partner_id = app_runtime.current_user_id()))
: ERROR: function app_runtime.current_user_id() does not exist

This is common in RLS-heavy schemas, where every policy calls a session helper such as app_runtime.current_user_id().

Validation

go test ./...

New acceptance case: a policy added to an existing table whose USING expression calls a function created in the same plan. Applying the plan is the assertion — the wrong order fails with function current_user_id() does not exist.