fix(0011): do not report aggregates as having a mutable search_path

[karpovantonme]

Fixes #139.

Problem

0011_function_search_path_mutable scans pg_proc without filtering prokind, so aggregates are reported alongside functions.

An aggregate's pg_proc row is a placeholder: it has no body, prolang is internal, and CREATE AGGREGATE has no SET clause, so proconfig is always null. The lint's "search path not set" condition is therefore always true for an aggregate, and there is no way for a user to resolve the warning.

Reproducing the report:

create function public.uuid_min(uuid, uuid) returns uuid
    set search_path = '' language sql immutable strict
    as $$ select least($1, $2) $$;

create aggregate public.min_uuid(uuid) (
    sfunc = public.uuid_min,
    stype = uuid,
    combinefunc = public.uuid_min,
    parallel = safe
);

public.min_uuid is reported even though every function it is built from pins its search path.

Fix

and p.prokind <> 'a'

The issue suggests filtering on prolang = internal instead. prokind is the narrower and more direct attribute: it excludes exactly the objects that cannot carry a SET clause, without also excluding internal- or C-language functions, which can.

Procedures (prokind = 'p') and window functions (prokind = 'w') are deliberately left in scope: both accept a SET clause, and a SECURITY DEFINER procedure with a mutable search path is a real finding.

No coverage is lost. An aggregate's support functions are ordinary pg_proc entries and are still reported on their own; the test asserts this by dropping the SET clause from the support function and checking that it, and not the aggregate, is flagged.

splinter.sql regenerated via bin/compile.py.

Verification

• docker compose -f dockerfiles/docker-compose.yml run --rm test on supabase/postgres:15.1.1.13 — all 28 tests pass.
• pre-commit run --all-files — all hooks pass.