fix(wecom): allow config-only unified startup without WECOM_CORP_ID env

[canyugs]

Summary

A complete first-class [wecom] section cannot start the unified WeCom adapter unless WECOM_CORP_ID is also present in the process environment.

This breaks the config-first contract introduced by #1382: individual fields correctly resolve config -> WECOM_* env -> default, but adapter detection still depends on the environment before the resolved WeCom config is applied.

Reproduction

Use a config containing only a complete WeCom adapter section:

[wecom]
corp_id = "ww1234567890abcdef"
secret = "test-secret"
token = "test-token"
encoding_aes_key = "abcdefghijklmnopqrstuvwxyzABCDEFGH123456789"
agent_id = "1000002"
allow_all_users = true

Ensure WECOM_CORP_ID and the other WECOM_* variables are unset, then run:

openab run -c config.toml

Current result:

Error: no adapter configured — add [discord], [slack], [telegram], or [gateway] to config, or set platform env vars (TELEGRAM_BOT_TOKEN, etc.)

Expected result: the unified gateway starts and mounts the configured WeCom webhook route using the [wecom] credentials.

Root cause

There are two config-blind startup gates in src/main.rs:

1. The no-adapter validation checks cfg.telegram.is_none() but does not consider cfg.wecom.
2. Embedded gateway initialization uses has_unified_platform_env() || cfg.telegram.is_some(). has_unified_platform_env() only checks WECOM_CORP_ID, not resolved [wecom] configuration.

The WeCom trust deprecation activity signal also uses only WECOM_CORP_ID; config-only activation should be considered there as well.

Impact

• Existing env-only WeCom deployments are unaffected.
• [wecom] configurations using literal values or non-WECOM_* secret substitution cannot start without redundantly exporting WECOM_CORP_ID.
• The field-level config resolution tests pass, so the current config-first conformance guard does not catch this startup-path regression.

Suggested acceptance criteria

• A complete [wecom] section starts the unified gateway with all WECOM_* variables unset.
• An incomplete [wecom] section continues to fail safely or leave the adapter disabled according to the existing validation contract.
• Adapter detection and trust migration warnings recognize config-only WeCom activation.
• Add a regression test covering config-only startup/adapter detection, not only WecomConfig::resolve().

Related: #1375, #1382.

Context

• Discord discussion

[github-actions]

⚠️ This issue is missing the following required information and will not be processed until completed:

• Expected Behavior

Please edit this issue to fill in the missing fields. Thank you!

Tip: Use headings like ## Description or ### Description — common synonyms (e.g. ## Problem, ## Reproduction, ## Motivation) are also accepted.