[Obsidian review blockers] - Step 2: Preserve provider request semantics

[logancyang]

Relates to logancyang/obsidian-copilot-preview#285

Why

Obsidian's review flags direct fetch use in Bedrock, Jina, and GitHub Copilot providers. Replacing every call with requestUrl would break streaming providers because requestUrl buffers the response body, while leaving scattered global-fetch calls makes the exception hard to audit.

What

Buffered provider requests use Obsidian's requestUrl API. Providers that require a readable response stream obtain native fetch through one active-window adapter, preserving the existing streaming contract and receiver binding.

Request kind	Before	After
Buffered Jina request	Global fetch	Obsidian requestUrl
Bedrock streaming	Window-bound global fetch inline	Audited active-window streaming adapter
GitHub Copilot streaming	Direct global fetch reference	Shared active-window streaming adapter

Non goal

• Redesign provider configuration or authentication.
• Replace streaming protocols with buffered responses.
• Rewrite provider architecture beyond a local transport boundary.
• Change persisted settings, credentials, or user data schemas.
• Address review findings outside provider transport in this stack step.
• Reimplement or authenticate against Obsidian's private review service.

Screenshot

Not applicable — this step changes provider request transport and has no visual behavior.

Risk

High

Criterion	Status	Reason
No behavior change, or a cosmetic/copy/docs/config change visible where it renders, or deterministic tests cover the changed behavior	❌	Receiver binding is deterministic, but live provider compatibility depends on third-party streaming services
A defect would fail CI or be obvious on first use	✅	A transport failure surfaces on the next affected provider request
A revert fully restores prior state, including persisted data	✅	No persisted data changes
No auth, permissions, secrets, or input-handling surface changes	❌	Provider HTTP transport is an external input/output boundary
No public API, plugin API, message, or on-disk contract changes	✅	Provider and plugin interfaces are unchanged
No core-path concurrency, async-lifecycle, or state-machine changes	❌	The core provider request path selects a different transport boundary
No hot-path behavior lacks deterministic coverage	❌	End-to-end streaming requires live Bedrock or GitHub Copilot services and credentials unavailable to CI
No new dependency	✅	Dependency manifests are unchanged
Human-only behavior stays in one feature area and surfaces quickly	✅	Any residual defect stays in provider requests and appears on the first request

Review: inspect src/network/streamingFetch.ts — getNativeStreamingFetch — and the transport selection in the four changed provider modules line by line, then run Verification steps 1–4.

Verification

1. Run npm test -- --runTestsByPath src/network/streamingFetch.test.ts --runInBand.
2. Run npm test -- --runTestsByPath src/LLMProviders/BedrockChatModel.test.ts --runInBand.
3. Run npm run build.
4. With configured credentials, send one streaming request through Bedrock and GitHub Copilot and one embedding request through Jina; confirm each returns normally.

Note

npm run format passes. The repo-wide npm run lint command still reports the review backlog tracked by issue #285; this commit's staged-file lint hook passes, and later stack steps remove that backlog.

[logancyang]

Conservative risk disposition

Risk: High (highest in the original stack) — deferred and removed from the required stack.

This PR touches provider HTTP and streaming semantics for Jina, Bedrock, and both GitHub Copilot adapters. Even a small transport change can affect authentication, streaming chunks, cancellation, custom endpoints, or response parsing, and the important paths require live-provider smoke tests.

The Obsidian findings here are warning-only, and the legacy Copilot v3 provider work is lower priority. Recommendation: close this PR and revisit it independently only when provider-specific integration coverage is available.