refactor(api): 原子构造 + 所有权进名字（v2.10 第一刀）

[adam-ikari]

v2.10 第一刀：构造面。方向与兼容策略见 brain api-atomization-orthogonalization（破坏性改、不留兼容层）。

新增：uvhttp_server_listen_routes —— 原子的构造入口

此前"起一个带路由的监听服务器"要 5 步，且没有原子版本，调用方被迫为每一步手写回滚：

const uvhttp_route_t routes[] = {
    {"/",        UVHTTP_ANY, hello},
    {"/health",  UVHTTP_GET,  health},
};
uvhttp_server_listen_routes(loop, routes, 2, "0.0.0.0", 8080, &server);

要么返回完全就绪、路由齐全的监听中的 server，要么什么都没创建（所有失败路径上 *server 为 NULL）。无中间态，无回滚可写。

修复：官方嵌入示例的 double-free（ASan 可复现）

examples/embedding/main.c 的 listen 失败分支在 set_router 已转移所有权之后仍调 uvhttp_router_free(router)，随后 uvhttp_server_free(server) 再释放一次。

重命名：所有权进函数名

• uvhttp_server_set_router → uvhttp_server_take_router
• uvhttp_server_set_context → uvhttp_server_take_context

"take" 明确表达所有权转移。同时这两个函数原先会静默覆盖已有指针（旧对象泄漏），现在返回 INVALID_PARAM 拒绝；重复 take 同一个对象仍为幂等，便于 teardown 路径复用。NULL 不是 detach：take 之后传 NULL 同样被拒 —— 头文件、代码注释、4 个新用例与 2 处旧测试注释都已说清这条语义。

删除：请求读取 API 的纯别名

uvhttp_get_header / uvhttp_get_param / uvhttp_get_body —— 三个函数体各只有一行转发，且声明在 server.h 里却不涉及 server；uvhttp_get_param 的 "param" 还有歧义（实为 query param）。

评审修复（第三个提交）

review 发现 5 项 P1，均为契约/文档诚实度问题（非内存安全问题，内存安全面经 ASan 探针逐条验证）：

• docs/spec/server-api.md 的 take_router Postconditions 曾写着"server 不持有 router，调用方应释放"——与头文件 OWNERSHIP TRANSFERS HERE 正相反，而它恰是引发 double-free 的那个误解。已改正，并补齐 take_context 与 listen_routes 两节
• 两个根 README 未被触及，快速开始仍调用已改名的 set_router（合并后照抄编译不过）
• ListenFailureLeavesNothingBehind 原用特权端口 1 制造失败，root 下 GTEST_SKIP → 本 PR 核心回归在该环境不被验证。改为先 uv_listen 占住端点端口再传同端口，必然 EADDRINUSE，与运行身份无关
• 新 API 在 spec / API 参考面缺席；method 越值会登记"永不匹配"的死路由，现已在写点拒绝
• 失败日志原先建议"free it first"——调用方无权单独释放 server 持有的对象（free 了就是 UAF）且 NULL 也卸不掉，改为给出可执行的出路

已按用户方案从本 PR 拆出：#472（14 个死配置字段与 4 个假旋钮 API）、#473（set_body 原子替换 + LRU setter 不变量）。

验证

ctest 120/120（含 ASan 全量）；method 校验经变异测试验证有牙齿；cppcheck 零告警；test-validity 门禁 PASS；build-matrix 5 种裁剪组合全过。