feat: server-side alerts filtering with operators and type param

[paragmore]

Improves filtering on the alerts endpoints (/auth/alerts/site, /auth/alerts/history) so callers can filter server-side instead of post-processing the response.

Operator-based filter — values can be a scalar (equality), an array ($in), or an operator object. Allowed operators: $eq, $ne, $in, $nin, $gt, $gte, $lt, $lte. Anything outside the field/operator allow-lists returns ERR_INVALID_FILTER.

?filter={"type":{"$ne":"miner"}}
?filter={"severity":["critical","high"]}

New type param (all | operational | miner) on both endpoints, validated by the route schema:

• omitted / all → everything
• miner → miner alerts only (matches the miner base type and subtypes like miner-am-s19xp)
• operational → everything except miners

It's ANDed with any explicit filter/search/sort/pagination, so existing behaviour is unchanged.

Thing-level filtering is pushed into the listThings / getHistoricalLogs queries; the handler re-applies the filter on the merged result for per-alert fields and multi-rack correctness. Site search also now matches the alert name.

Consistency: both endpoints now expose the device type as type (history previously returned deviceType) and carry container + position, so the Position column is populated.

Notes:

• Filters with unknown fields/operators now error instead of being silently ignored.
• History device-type filter field is now type (was deviceType).
• History pushdown depends on feat: apply query filter to getHistoricalLogs alerts miningos-tpl-wrk-thing#21 — until that ships, history filtering still works via the handler re-filter.