GTM API / Update LinkedIn account smart limit

GATE: on a governed account (smart_limits_enabled true, the default) daily_limit / delay_in_seconds belong to the warmup; moving either is 409 smart_limits_governed: never promise a raised cap there. target_limit only BOUNDS (the row follows min(smart_limit, target_limit)): a target above the warmup ceiling changes nothing today; a young or dormant account sits at 1..2 for weeks (see warmup_breakdown). The other way: set_linkedin_account_smart_limits({enabled:false}), said out loud as removing ban protection. One row (daily_limit / target_limit / delay_in_seconds / learning_enabled; one field OR reset_hold:true). Switch off: nothing refused; read the row's recommended_* first, 2x (or half the delay) is "elevated", beyond that "ban_likely", warn so. A spent budget is "held": raising daily_limit alone does not clear it, pass reset_hold:true too; it resumes once the cap exceeds done_today_count (governed rows re-hold at once). System fields are rejected; a LinkedIn lock is not resettable. Contract: - MCP tool update_linkedin_account_smart_limit, registry package mcp.linkedin/linkedin_account_smart_limits, mount linkedin.accounts. - Operation update, response envelope update. - Flags: dangerous: the MCP layer gates it behind a preview/commit token, and the effect cannot be undone through this API.