fix: isolate backwards invocation contexts - #788

Description

PluginManager currently returns one shared BackwardsInvocation. Plugin sessions mutate that instance with their HTTP request context. After a request finishes, its canceled context can therefore leak into later endpoint setup or listing calls, causing /inner/api/invoke/encrypt to fail locally with context canceled before the request reaches Dify API.

Fixes #787

Root cause

Session.propagateTraceContext calls SetContext on the invocation returned by PluginManager. Because the manager returned its stored singleton directly, the session replaced the singleton's context. The canceled request context then remained attached to all later callers.

Changes

• adds WithContext to create a context-bound invocation copy while reusing the HTTP client and immutable configuration
• returns a fresh invocation from PluginManager.BackwardsInvocation()
• preserves per-session cancellation by propagating the active request context only to that session's copy
• updates the mock implementation and adds regression tests for both the concrete invocation and manager behavior

Type of Change

• Bug fix
• New feature
• Refactor
• Performance improvement
• Other

Essential Checklist

Testing

• I have tested the changes locally and confirmed they work as expected
• I have added unit tests where necessary and they pass successfully

Bug Fix (if applicable)

• I have used GitHub syntax to close the related issue (e.g., Fixes #123 or Closes #123)

Additional Information

Validation performed locally:

go run cmd/license/generate/main.go
go test -v -timeout 1m ./cmd/... ./internal/... ./pkg/...
go test -race ./internal/core/plugin_manager ./internal/core/dify_invocation/calldify ./internal/core/session_manager

The full unit test suite and focused race tests pass. A control test on the unmodified main branch reproduces the same context canceled error, while the patched branch completes the request successfully.