chore(deps): bump @ecency/sdk to 2.3.81

[feruzm]

Bumps @ecency/sdk from 2.3.80 to 2.3.81, which is the release of ecency/vision-web#1404.

#3480 landed on 2.3.80, so it has the pagination direction fix but not these two follow-ups:

• The walk could not reach the head of history. condenser_api.get_account_history asserts start >= limit - 1. The cursor is derived from num alone, so the last window before the start of history was shorter than limit and the request failed the assert rather than returning the remaining rows. The SDK now narrows the requested limit for that final window.
• fill_transfer_from_savings ignored the per-asset filter. It had no case in the HIVE/HBD select switches, so filtering for it on HIVE also listed completed HBD withdrawals, and the reverse. It now carries the same symbol guard as transfer_from_savings.

Both are transparent to callers, so nothing in the app changes beyond the dependency.

Verification

• yarn.lock moves only the @ecency/sdk entry, nothing else re-resolved.
• Installed tree confirmed on 2.3.81 and carrying the fix.
• tsc --noEmit — 1 error, src/components/imageViewer/imageViewer.tsx(176,7), doubleTapScale not on Props. Pre-existing: a clean install of development at 2.3.80 reports the same single error, so it is unrelated to this bump. Worth a separate issue.
• The four has no exported member errors seen against an older locally-installed SDK are gone once the tree matches the lockfile.

[coderabbitai]

Warning

Review limit reached

@feruzm, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 19 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 30759511-4926-4a11-9724-78f74cee6ea1

📥 Commits

Reviewing files that changed from the base of the PR and between 5896a46 and 9f75a13.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (1)

• package.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[feruzm]

Correction to the verification section above: the claim that the imageViewer.tsx(176,7) typecheck error is pre-existing on development and worth its own issue is wrong. There is no bug, and no issue is needed.

doubleTapScale is a valid prop. patches/react-native-image-viewing+0.2.2.patch adds it, and it is applied by postinstall: npx patch-package. My verification installs all used yarn install --ignore-scripts, so the patch never landed and the prop was missing from Props. Running npx patch-package on the same tree:

typecheck ok: 0 errors (baseline 0)

Two related corrections:

• I described the error as reproducing "on a clean install of development", which read as independent confirmation. It was not. Every install shared the same --ignore-scripts flag, so it was the same artifact three times.
• The gate is node scripts/typecheck.js, a per-file comparison against tsc-baseline.json that fails only on regressions, not the bare tsc --noEmit I ran. The baseline is currently {"total": 0, "files": {}}.

CI was green throughout and was right. Nothing here needs following up.