import { sql } from 'slonik';
/**
 * Multi-business read scope for the securities tables.
 *
 * `2026-05-25T10-00-00.rls-multi-business-scope.sql` switched every
 * `tenant_isolation` read predicate to
 * `owner_id = ANY (accounter_schema.get_current_business_scope())`, leaving writes pinned to
 * the single `get_current_business_id()` target. All four securities tables were created
 * *after* that migration (2026-08-11 / 08-13 / 08-20) and so were never in its list — they
 * still read through the singular helper.
 *
 * The consequence is a silent narrowing rather than a leak: a request whose authorized scope
 * spans several businesses sees securities for only one of them, with nothing in the response
 * saying so. That breaks the web client's business switcher and, more sharply, the MCP
 * connector, which forwards its resolved read scope as `x-business-scope` and echoes it back
 * to the caller (`docs/coherent-owner-scoping-for-mcp/plan.md`).
 *
 * Predicates are deliberately byte-identical to the earlier migration's: reads follow the
 * request's scope, writes stay on the explicit write target, so the scraper ingestion path is
 * unaffected.
 */
declare const _default: {
    name: string;
    run: ({ connection }: {
        sql: typeof sql.unsafe;
        connection: import("slonik").DatabaseTransactionConnection | import("slonik").DatabasePool;
    }) => Promise<void>;
};
export default _default;