refactor(flaresolverr): replace module-global state with a configured client

[Rushaway]

Summary

• The bypass URL was a module-level global reassigned via set_flaresolverr_url() on every Init(), with a module-level session next to it — configuration living in mutable global state rather than owned by anything.
• FlareSolverr is now a small class holding its own URL and session. Torchlight builds one from config (falling back to the previous http://127.0.0.1:8191/v1 default when there's no FlareSolverr section), and FFmpegAudioPlayer reaches it via self.torchlight.flaresolverr.

A leak this surfaced

Init() re-runs on every reconnect (OnDisconnect → Init()). That didn't matter while the session was global — it was reused across re-inits. Now that each Torchlight owns one, a naive port would leak an aiohttp session per reconnect. So Init() now closes the outgoing instance's session before replacing it, and __del__ closes the current one (guarded with getattr, since __del__ can run before/after attributes exist).

Closes #159

Test plan

Against a live local stub of the FlareSolverr API:

• URL derived from config → http://10.0.0.5:9999/v1.
• No FlareSolverr config section → falls back to the previous default, unchanged.
• get_cf_session returns the parsed cookies/user-agent and reuses the same session across calls (the pooling win from fix(flaresolverr): reuses a pooled session instead of opening one per call #144 is preserved).
• close() closes the session and clears the reference.
• Two instances hold independent URLs — no shared global state anymore.
• No dangling references to the removed set_flaresolverr_url/close_cf_session; all modules compile.

🤖 Generated with Claude Code

[Rushaway]

Self-review: the non-obvious part is that moving the session off the module global introduces a per-reconnect leak unless Init() closes the outgoing one -- Init() runs on every OnDisconnect, so that would have quietly accumulated aiohttp sessions on a flappy SMAPI link. Handled it explicitly and verified session reuse still works so #144's pooling benefit isn't lost. @Dolly132 this touches the close_cf_session wiring you added in #144, so worth your eyes specifically.

[Dolly132]

Tested, works fine as intended.