fix(release): stabilize bundled plugin validation and tests

[linfangw]

Summary

• Problem: release validation and pnpm test were blocked by a few fork-specific regressions: sparse env snapshots could hide bundled provider metadata, some bundled channel config-schema entrypoints were still too broad, mocked fetch tests still performed real DNS lookups before hitting the stub, and the X bundled channel surface still had a couple of package-boundary gaps.
• Why it matters: scripts/release-npm.sh and release-time verification could fail even when the visible shard summary looked green, which blocked publish-time confidence for the QVerisBot fork.
• What changed: preserved host/plugin discovery context for sparse env snapshots, added package-local config barrels for bundled channel schema entrypoints, fixed mocked-fetch SSRF-guard behavior so tests do not do real DNS before the stub, kept Ollama ambient discovery test-only opt-in explicit, added the missing bundled runtime sidecar path for x, and normalized X messaging targets more consistently.
• What did NOT change (scope boundary): no intentional user-facing provider auth semantics, network policy behavior in production, or release process steps outside these bundled/test regressions.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #N/A
• Related #N/A
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: several bundled/plugin-facing paths still relied on assumptions that were safe in the upstream tree but brittle in the forked release/test flow: sparse env snapshots dropped host context needed for bundled plugin discovery, bundled config entrypoints imported too broadly, and the SSRF guard did real pinned-DNS resolution before mocked fetch implementations in tests could intercept the request.
• Missing detection / guardrail: there was no regression coverage for mocked global fetch paths without a custom lookup, and release/test validation only surfaced the issue once multiple extension suites ran together under the packaged fork environment.
• Contributing context (if known): the forked package and bundled-plugin validation path exercises more installed/package-boundary code paths than a simple local unit run, so these mismatches escaped until release verification.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/infra/net/fetch-guard.ssrf.test.ts, src/secrets/provider-env-vars.test.ts, src/agents/models-config.providers.ollama.test.ts, extensions/msteams/src/oauth.test.ts, extensions/google/image-generation-provider.test.ts, extensions/venice/models.test.ts, extensions/xai/x-search.test.ts, extensions/xai/code-execution.test.ts, extensions/mattermost/src/channel.test.ts.
• Scenario the test should lock in: mocked fetch-based extension tests must not perform real DNS before the stub runs; sparse env snapshots must still retain bundled provider auth metadata; bundled channel config-schema entrypoints must stay on package-local/public seams; X bundled entry/runtime sidecars must remain aligned.
• Why this is the smallest reliable guardrail: the unit tests pin the helper behavior cheaply, while the targeted extension suites are the smallest reliable place where the release/test regressions actually surfaced.
• Existing test that already covers this (if any): the extension/provider suites above already exercised the broken paths once the helper behavior was corrected.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• x messaging target normalization is stricter and more consistent for prefixed user ids and twitter.com profile URLs.
• Release/test behavior changes: bundled validation and extension test suites no longer fail because mocked fetch paths try real DNS first.

Diagram (if applicable)

Before:
[extension test with mocked fetch] -> [SSRF guard does pinned DNS first] -> [real DNS failure] -> [pnpm test exits non-zero]

After:
[extension test with mocked fetch] -> [hostname policy check only] -> [mocked fetch receives request] -> [suite result reflects actual test assertions]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local checkout, Node 24.2.0, pnpm
• Model/provider: N/A
• Integration/channel (if any): bundled providers/channels including MSTeams, Google, Venice, XAI, Mattermost, Ollama, Google Chat, Telegram, X
• Relevant config (redacted): fork package @qverisai/qverisbot, local test/home isolation enabled by repo Vitest setup

Steps

1. Run env OPENCLAW_LOCAL_CHECK=0 pnpm test or invoke scripts/release-npm.sh on the fork.
2. Observe extension/provider suites fail even though a later shard summary can show all tests green.
3. Apply this PR and rerun the same verification commands.

Expected

• pnpm test and release validation complete without false-negative failures from bundled validation or mocked-fetch DNS behavior.

Actual

• Before this PR, multiple extension/provider suites failed with ENOTFOUND because mocked fetch paths still performed real DNS first, and bundled/forked config paths had a few boundary mismatches.
• After this PR, the targeted regressions and full pnpm test pass.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: node scripts/run-vitest.mjs run src/infra/net/fetch-guard.ssrf.test.ts extensions/msteams/src/oauth.test.ts extensions/google/image-generation-provider.test.ts extensions/venice/models.test.ts extensions/xai/x-search.test.ts extensions/xai/code-execution.test.ts extensions/mattermost/src/channel.test.ts, env OPENCLAW_LOCAL_CHECK=0 pnpm test, and the commit hook's pnpm check gate.
• Edge cases checked: mocked global fetch with no custom lookup, explicit wrapper fetch functions around mocked global fetch, sparse env snapshots for bundled provider auth env vars, test-only Ollama ambient discovery opt-in, bundled config-schema local barrels, and X messaging target normalization.
• What you did not verify: actual npm publish, registry install after publish, or post-publish smoke on a published artifact.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: the mocked-fetch bypass in fetch-guard could accidentally mask a future production-path regression if it were allowed to apply too broadly.
  • Mitigation: it is narrowly gated to mocked fetch without explicit lookup/dispatcher overrides, and regression coverage now exercises both the ambient mocked fetch path and an explicit wrapper fetch path.
• Risk: the bundled config barrel changes could drift if future extension config entrypoints start importing broader plugin barrels again.
  • Mitigation: the bundled extension config API guardrail test now points at the package-local seam and will fail if the boundary regresses.

[gemini-code-assist]

Code Review

This pull request introduces messaging target normalization for the X plugin, adds environment-based controls for Ollama provider discovery, and implements package-local configuration barrels for several extensions. It also refines environment variable resolution and allows bypassing pinned DNS lookups in the SSRF guard when using mocked fetch implementations. Review feedback suggests optimizing the X plugin's normalization regex for redundancy and consistency, and narrowing the mocked fetch detection logic to avoid unintentionally disabling security protections in shared test suites.