refactor(client): deepen config construction and remove ClientBuildConfig

[foxzool]

Problem Statement

OpenLark 用户目前可以通过 ClientBuilder 或现成的 core Config 构造 Client，但两条路径背后维护了平行的配置状态、环境变量解释和校验 implementation。这种重复已经造成可观察缺陷：ClientBuilder 接受 allow_custom_base_url(true)，转换时却可能丢失该设置；Client::with_core_config 又使用较弱的重复校验，使非白名单域名在没有显式放行时仍可能进入 Client。

对 SDK 用户而言，这意味着看似相同的配置在不同构造入口可能产生不同结果，安全开关也不能可靠地兑现。对维护者而言，每增加一个配置字段，都必须同步修改多份状态和转换逻辑，遗漏后只能等到运行时或安全审查才能发现。

Solution

将 core ConfigBuilder 深化为配置状态、默认值、环境覆盖和 header 合并的唯一 implementation。ClientBuilder 保留现有公开 interface，但只委托 core builder，并仅保留 Client 特有的 30 秒默认超时和严格构造策略。

ClientBuilder::build 与 Client::with_core_config 穿过同一个私有构造 seam。该 seam 统一执行 core 配置校验、Client 零超时校验、错误 context、registry 初始化、token provider 注入和 Client 组装。

删除平行的 ClientBuildConfig、逐字段转换以及重复的 Client 校验。core 的宽松构建契约保持不变；只有 Client 构造入口继续严格校验。非白名单域名必须显式设置 allow_custom_base_url(true)，从而恢复 issue #150 已确定的安全契约。

User Stories

1. As an OpenLark SDK user, I want existing Client::builder() calls to keep compiling, so that the refactor does not require source migration.
2. As an OpenLark SDK user, I want ClientBuilder to retain its 30-second default timeout, so that existing request timing behavior remains stable.
3. As a core configuration user, I want core ConfigBuilder to retain its no-timeout default, so that independent core callers are not silently constrained.
4. As a core configuration user, I want ConfigBuilder::build() to remain non-validating, so that the existing permissive construction contract is preserved.
5. As a security-conscious SDK user, I want non-Feishu/Lark base URLs rejected by default, so that credentials and tokens are not accidentally sent to an untrusted host.
6. As an SDK user with an intentional proxy or mock server, I want allow_custom_base_url(true) to be preserved through Client construction, so that explicitly authorized custom hosts continue to work.
7. As an SDK user supplying a core Config, I want Client::with_core_config to enforce the same hostname rules as ClientBuilder, so that constructor choice does not change the security contract.
8. As an SDK user, I want an unset core timeout accepted by Client::with_core_config, so that core's no-timeout configuration remains valid.
9. As an SDK user, I want a zero timeout rejected by Client construction, so that an unusable Client fails early with a clear validation error.
10. As an operator, I want environment variables applied at the point where from_env() or load_from_env() appears in the chain, so that override order is predictable.
11. As an operator, I want missing or empty environment variables to preserve existing builder values, so that partial environment configuration does not erase code defaults.
12. As an operator, I want invalid numeric values and unknown application types ignored as before, so that this refactor does not introduce unrelated environment-loading failures.
13. As an SDK user, I want a setter called after environment loading to override the environment value, so that explicit code configuration can take precedence.
14. As an SDK user, I want environment loading called after a setter to override that setter when a valid environment value exists, so that chain order remains meaningful.
15. As an SDK user, I want to add one header without replacing the existing header map, so that incremental request configuration remains convenient.
16. As an SDK user, I want duplicate header keys resolved by last write, so that header behavior is deterministic.
17. As an SDK user, I want whole-map header replacement and incremental header insertion to follow chain order, so that mixed usage is unambiguous.
18. As a maintainer, I want each configuration field stored in one canonical state, so that new fields cannot drift between core and Client representations.
19. As a maintainer, I want environment variable parsing implemented once, so that adding an environment-backed field requires one change.
20. As a maintainer, I want general validation implemented once in core, so that error fields, whitelist rules, and retry limits stay aligned.
21. As a maintainer, I want the Client-specific zero-timeout rule localized to Client construction, so that core callers are not subject to an unintended stricter policy.
22. As a maintainer, I want both public Client construction entries to use one private seam, so that initialization ordering and context cannot diverge.
23. As a maintainer, I want private field-mirroring tests removed, so that internal restructuring does not require rewriting behaviorally irrelevant tests.
24. As a test author, I want to verify configuration through the built Config or Client, so that tests exercise the same interface as callers.
25. As a test author, I want environment tests serialized and isolated, so that process-global state does not make the suite flaky.
26. As a support engineer, I want validation errors to retain an accurate category and field, so that recovery guidance remains actionable.
27. As a support engineer, I want errors to identify whether ClientBuilder::build or Client::with_core_config failed, so that reports can be traced to the correct caller path.
28. As a security reviewer, I want builder debug output to omit secrets, token provider details, and header contents, so that diagnostic logs cannot disclose sensitive configuration.
29. As a release maintainer, I want the custom-host propagation and whitelist enforcement fixes recorded in the changelog, so that the tightened behavior is visible to adopters.
30. As a future contributor, I want the shallow Client configuration mirror deleted rather than patched, so that the same class of drift cannot recur.

Implementation Decisions

• The core configuration module is the canonical module for configuration state, defaults, environment interpretation, header merging, and general validation.
• ConfigBuilder will directly hold the canonical private configuration state instead of a parallel collection of optional fields.
• Existing ConfigBuilder setters and the behavior of build() remain unchanged from a caller perspective.
• ConfigBuilder gains load_from_env() for ordered environment overlay and add_header() for incremental header insertion.
• Static environment construction, mutation of an existing Config, and builder overlay must share one private environment interpretation implementation.
• ClientBuilder will directly hold core ConfigBuilder; it will not mirror configuration fields.
• Existing ClientBuilder setters remain available and delegate to core builder.
• ClientBuilder::new() applies the Client-specific 30-second timeout over core defaults.
• ClientBuilder::build and Client::with_core_config use one private construction seam.
• The private construction seam owns validation and initialization ordering; callers are not required to validate first.
• Config::validate() remains the only implementation for credentials, URL scheme, domain whitelist, and retry-count rules.
• Client construction adds only the zero-timeout rule. A missing timeout remains valid for Client::with_core_config.
• A custom host is accepted only when allow_custom_base_url(true) is explicitly present in the canonical configuration state.
• Validation errors use CoreError, preserve the validation category and accurate field, and use core's canonical wording.
• Error strings are not required to remain byte-for-byte compatible with the removed duplicate implementation.
• Construction errors retain operation context for the public entry that was used. Registry initialization errors also retain the service_loading context.
• Environment overlay follows call order. Missing, empty, or unparsable values preserve the current builder state.
• Incremental headers use last-write-wins. Whole-map replacement and incremental insertion follow call order.
• ClientBuilder retains Clone and a redacted Debug implementation. Debug output must not include secrets, token provider internals, or header values.
• The parallel Client configuration state, its conversion, and its duplicate validation are deleted rather than deprecated because they are private implementation details.
• No configuration policy interface, profile abstraction, port, or adapter is introduced. All dependencies are in-process, and no second varying implementation justifies another seam.
• The earlier creation of the default HTTP client when a core builder is created is an accepted implementation trade-off for canonical state and higher locality.
• Release notes will identify the security tightening, custom-host propagation fix, and normalized validation wording.

Testing Decisions

• Good tests assert observable results through core ConfigBuilder, ClientBuilder::build, or Client::with_core_config. They do not inspect private builder fields or call removed validation helpers.
• Core configuration tests cover the no-timeout default, ordered environment overlay, ignored invalid environment values, incremental header insertion, whole-map replacement order, custom-host flag retention, cloning, and redacted debug output.
• Client construction tests cover the 30-second default, custom-host rejection and explicit allowance, equal whitelist behavior across both public constructors, valid missing timeout, rejected zero timeout, and preserved final configuration.
• Error tests assert category, field, and operation context rather than legacy wording.
• Environment tests use the repository's existing serialized environment-variable fixture pattern to avoid process-global races.
• Existing core configuration tests are the prior art for builder defaults, environment loading, whitelist validation, and custom-host behavior.
• Existing Client construction tests are the prior art for observing final configuration through Client::config() and for validating both construction entries.
• Tests tied only to the removed private configuration mirror are deleted. Any behavior they uniquely protected is migrated to the highest surviving interface.
• Verification includes focused core and Client tests, formatting, both all-feature and no-default-feature clippy modes, and workspace compilation checks.
• Changelog assertions are reviewed alongside behavior tests so that the security tightening and compatibility contract remain documented.

Out of Scope

• Making core ConfigBuilder::build() automatically validate.
• Changing core's default timeout.
• Removing or renaming existing public ClientBuilder setters.
• Introducing public configuration policies, profiles, overlays, ports, or adapters beyond the two approved builder additions.
• Changing registry structure, token acquisition behavior, request execution, or business-crate construction.
• Adding strict errors for malformed optional environment values that are currently ignored.
• Guaranteeing byte-for-byte compatibility of validation messages.
• Redesigning the SDK's broader error hierarchy.
• Changing the Feishu/Lark domain whitelist itself.

Further Notes

• This work completes a follow-up explicitly left outside the earlier deprecated Config merge: the Client-side duplicate validation and construction state were retained temporarily and are now showing real drift.
• Issue security: base_url 缺少域名白名单校验，可能导致 Token 外泄 [Critical] #150 is the source of the custom-host opt-out security contract. This spec restores that contract consistently across both Client construction entries.
• The confirmed deletion test is central to the design: removing the private Client mirror makes complexity disappear into the canonical core module rather than pushing it into callers.
• The repository currently has no domain glossary term that needs to be introduced for this implementation-level configuration work.

[foxzool]

关闭说明

#413 父议题的 expand-contract 已全部落地并合入 main：

切片	Issue	PR	内容
expand	#414	#417	core ConfigBuilder 持有 canonical ConfigInner；load_from_env / add_header
migrate	#415	#418	ClientBuilder 委托 core builder；30s 默认；删字段镜像
contract	#416	#419	with_checked_core_config 统一双入口；删 client_build_config；修 with_core_config 白名单

完成标准核对

• ClientBuildConfig 与重复校验已删除
• allow_custom_base_url 经两条构造路径正确传播
• 双入口同一白名单 + 零超时规则
• core req_timeout=None / Client 默认 30s
• env / header 顺序由接口测试锁定
• CHANGELOG 记录安全收紧

后续边角：utils::create_config_from_env 将委托 core env 解释（独立小改），不阻塞本父议题关闭。