Apply parseMaxMessages pattern to limit and other numeric option args

[kiki830621]

Problem

From verification of #8/#11/#12 by devils-advocate (MEDIUM):
「一致性問題 — Server.swift 其他 numeric option args 仍有同款 silent fallback：

374: let limit = args["limit"]?.intValue ?? 50
387: let limit = args["limit"]?.intValue ?? 20
446: let limit = args["limit"]?.intValue ?? 50
454: let limit = args["limit"]?.intValue ?? 200

這些 limit 欄位都有同款 silent-fallback 缺陷：

• .string("0") → silently fall back to default
• .double(20.0) → silently fall back to default

#8 A1 的 logic「靜默 fallback 是 bug」對所有 numeric option args 都成立。Batch 3 只 fix max_messages，limit 沒 fix。」
— Source: team:devils-advocate

Type

bug (consistency)

Expected

把 parseMaxMessages 風格擴展到所有 Server.swift 的 numeric option args：

internal func parseLimit(_ args: [String: Value], default defaultValue: Int) throws -> Int {
    guard let raw = args["limit"] else { return defaultValue }
    guard let value = Int(raw, strict: false) else {
        throw HandlerArgError(message: "limit must be an integer")
    }
    if value <= 0 {
        throw HandlerArgError(message: "limit must be positive; got \(value)")
    }
    // 視 handler 而定加上 upper bound
    return value
}

或：抽更通用的 parsePositiveInt(_ args:_ key:default:) throws -> Int。

Acceptance

• Server.swift:374, 387, 446, 454 的 4 處 limit ?? N 改用新 helper
• .string("invalid") for limit throws (not silently default)
• .double(0.5) for limit throws
• Tests for each handler's limit validation
• CHANGELOG entry

Code Reference

• Sources/CheTelegramAllMCPCore/Server.swift:374, 387, 446, 454
• Sources/CheTelegramAllMCPCore/HandlerArgs.swift:115 (parseMaxMessages — pattern source)

Related: #8 (extends pattern from max_messages to limit)