fix: reject inbound messages on expired sessions (WAPI-1130)

[chakra-guy]

Summary

• Adds session expiry check to the inbound message handler in BaseClient, closing a gap where only outbound messages were checked for expiry
• Expired inbound messages are silently discarded with an error event emitted and disconnect triggered

Background

The Cyfrin audit identified that while sendMessage() checks for session expiry before sending, the transport.on("message", ...) handler did not perform any expiry check. This meant a message arriving on an expired session would still be decrypted and processed.

Changes

• packages/core/src/base-client.ts: Unified checkSessionExpiry() method (returns boolean, handles disconnect + error emission). Used in both the inbound message handler (early return) and sendMessage (throws after check).
• packages/core/src/base-client.integration.test.ts: New test case for expired session message rejection
• apps/integration-tests/src/end-to-end.integration.test.ts: New E2E test verifying messages sent to an expired receiver are dropped and trigger SESSION_EXPIRED

Test plan

• yarn build passes
• yarn test:unit passes (63/63 tests)
• yarn lint passes (no new warnings)
• Integration tests pass (8/8 tests, including new expired session test)

---

Note

Medium Risk
Touches core message-handling and session lifecycle behavior; an incorrect expiry check or disconnect side effect could drop legitimate traffic or cause unexpected disconnects.

Overview
Expired sessions now block inbound traffic. BaseClient adds a session-expiry gate in the transport message handler so messages arriving after expiresAt are rejected, a SESSION_EXPIRED error is emitted, and cleanup/disconnect is triggered.

checkSessionExpiry() is refactored to return a boolean and is reused by both inbound and outbound paths, with new integration/E2E tests asserting that post-expiry messages are not delivered. Dependency housekeeping pins eciesjs to 0.4.17 across apps/core (and updates yarn.lock) and records the fix in the core changelog.

^{Written by Cursor Bugbot for commit 9827ff0. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[adonesky1]

LGTM!

[jiexi]

is the confirmNonce logic meant to be in this PR?

The base branch was changed.

[chakra-guy]

is the confirmNonce logic meant to be in this PR?

nope, it was just originally based in top of another pr that got mixed it after a merge conflict