v1.15.0 — apply runs out of process

Fixes the intermittent login failures some instances saw around plugin activity (#142).

Standalone apply was the last plugin action doing heavy DB work inside the gevent web worker. When it stalled a worker, nginx kept round-robining into it, so login — a multi-request flow — failed for roughly a quarter of attempts, and the 3/minute throttle then locked out the retries. It presented as "I can't log into Dispatcharr", not as a slow plugin.

It survived both earlier fixes aimed at it: after 1.7.1 shrank the apply transaction to sub-second and 1.8.x closed the scheduler's leaked DB connection, a 0.55s apply on a warm container still produced a 20s login timeout. Rather than keep hunting the exact blocking call with tools that cannot see individual greenlets, apply now forks the same subprocess refresh and auto_pipeline already use. No plugin action does bulk DB work in the web worker any more.

Nothing changes in how you use it. Apply still waits and still shows the real summary (unlike refresh, which returns immediately and reports through Show current state). The only difference you may notice is one to two extra seconds while the child starts up. auto_pipeline is unchanged — refresh and apply still run inside one child, not two.

Verified live: apply confirmed executing in the child, 1.6-2.2s end to end, login answering in ~0.4s while an apply was in flight, and the same 6 channels / 12 streams in the database afterwards.