fix: handle object-form ipBlocks in routeplanner status

[snakkeeh]

Changes

Fixed GET /v4/routeplanner/status crashing with
TypeError: ipBlocks[0]?.includes is not a function when route planner
ipBlocks are configured as { cidr } objects (which the canonical config
type allows). Added a getFirstBlockCidr() resolver that accepts string
entries, { cidr } objects, and missing/empty config, and made the
endpoint's local ipBlocks type match Array<string | { cidr: string }>.
Mirrored the fix in dist/src/api/routeplanner.js since dist is tracked.

Why

The endpoint's local type (ipBlocks: string[]) disagreed with the real
config type, so any object-form block config (valid per types, migration,
and route planner manager normalization) took down the status route with a
500 instead of returning the Lavalink-compatible payload.

Checkmarks

• The modified endpoints have been tested.
• Used the same indentation as the rest of the project.
• Still compatible with LavaLink clients.

Additional information

Verified with a temporary node:test suite (deleted before commit): string
blocks -> Inet4Address, object blocks -> Inet6Address with no throw,
missing ipBlocks -> defaults safely. tsc --noEmit passes. Commit follows
repo convention (fix: ..., <=72 chars, no scope, no trailing period).

[github-actions]

All Contributors have signed the CLA. The PR is now allowed to be merged.
_{Posted by the CLA Assistant Lite bot.}

[snakkeeh]

I have read the CLA Document and I hereby sign the CLA