chore: test preview effection with createApi support

[taras]

Summary

• Add pnpm override to use effection from PR feat: export createApi from main module effection#1116
• This PR is to observe which tests fail/hang with preview effection

Context

The createApi feature needed for middleware support in fetch/process/fs
packages is only available in preview effection. This PR tests the impact
of using preview effection across the monorepo.

Expected Failures

Based on local testing, these tests are expected to fail due to scope
teardown timing changes:

• effect-ts: 2 tests
• stream-helpers: 1 valve test

Related PRs

• feat(fetch): add fetchApi with middleware support #158 (fetch)
• feat(process): add processApi with middleware support #159 (process)
• feat(fs): add fsApi with middleware support #160 (fs)

Summary by CodeRabbit

• Chores
  • Updated internal dependencies to support development improvements.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR updates the effection devDependency from version ^4 to a GitHub PR URL and adds a corresponding PNPM override to ensure consistent dependency resolution during testing.

Changes

Cohort / File(s)	Summary
Package Dependencies package.json	Updated effection devDependency to a GitHub PR URL (https://pkg.pr.new/thefrontside/effection@1116) and added matching PNPM override for consistent resolution.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: testing a preview version of effection with createApi support by updating the package dependency.
Description check	✅ Passed	The pull request description provides clear motivation, approach, context, and expected outcomes, covering the key aspects beyond the minimal template requirements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main
Policy Compliance	✅ Passed	PR modifies only devDependencies and pnpm overrides; root package is marked private, so metadata policy does not apply; version bump policy exempts dev-only changes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/preview-effection-alpha

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

package.json (1)

19-36: ⚠️ Potential issue | 🟠 Major

Add a semantic version bump for this package.json change.

Policy requires a version bump when package.json changes; this file has no version field. Please add and bump the version appropriately (or document an explicit exemption for the private root package).
As per coding guidelines, “If package.json changes, include a semantic version bump.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@package.json` around lines 19 - 36, The package.json change requires a
semantic version bump: add or update the "version" field in package.json (e.g.,
increment patch from the current release to a new semver like "1.0.1") so the
commit includes a clear version change; alternatively, if this is an intentional
private root package, add an explicit "private": true entry and document that
exemption in the PR description. Ensure you update the "version" key
consistently and mention the reason (bumped for package.json changes) in the
commit message.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@package.json`:
- Around line 19-36: The package.json change requires a semantic version bump:
add or update the "version" field in package.json (e.g., increment patch from
the current release to a new semver like "1.0.1") so the commit includes a clear
version change; alternatively, if this is an intentional private root package,
add an explicit "private": true entry and document that exemption in the PR
description. Ensure you update the "version" key consistently and mention the
reason (bumped for package.json changes) in the commit message.