Fix subscribe:true flag for PUT operations

[sanity]

Summary

• Fixed subscription logic in PUT operations to properly subscribe the initiating peer
• Added comprehensive unit test to verify UPDATE operations work after PUT with subscribe:true
• Resolves River chat UPDATE failures that occurred after creating rooms

Problem

The subscribe: true flag on PUT operations was not properly subscribing the initiating peer to the contract. This caused UPDATE operations to fail with "missing contract" errors, particularly affecting River chat functionality.

Solution

1. Fixed subscription logic: Removed the is_seeding_contract check that was preventing subscription
2. Added contract verification: Verify the contract is queryable locally before subscribing
3. Proper subscription request: Use try_get=true to handle cases where contract isn't fully available
4. Local subscriber registration: Ensure the peer is registered as a local subscriber

Testing

• Added comprehensive unit test test_put_subscribe_enables_update that verifies:
  • PUT with subscribe:true properly subscribes the initiating peer
  • Subsequent UPDATE operations succeed without requiring separate SUBSCRIBE
• Manually tested with River chat:
  • Created room successfully
  • Sent messages (UPDATE operations) successfully
  • Messages persist and can be retrieved

Test Results

✓ Room creation successful
✓ Message sending (UPDATE) successful  
✓ Messages retrieved correctly

Fixes #1765

🤖 Generated with Claude Code

[sanity]

Rebasing to pick up recent CI fixes from main

[sanity]

Test Debugging Results

I've systematically investigated the failing test_put_with_subscribe_flag test. Here are my findings:

Root Cause Analysis

The test failure is not related to the subscribe flag fix itself, but rather to how the test manages client connections:

1. Test Logic Succeeds: The test successfully verifies that PUT with subscribe:true works - client 1 receives the update notification as expected
2. Client Disconnection Issue: When the test closure completes, both WebSocket clients are dropped
3. Node Failure: This causes the client events task to exit with "channel closed", which node.run() treats as a fatal error

Fixes Applied

1. Combinator panic fix (commit 56960a2): Changed client_events/combinator.rs to handle client disconnection gracefully instead of panicking
2. Attempted client lifetime fix (commit 60a2884): Modified test to return clients from closure to keep them alive longer (this didn't fully resolve the issue)

Remaining Issue

The fundamental problem is architectural: the node considers it an error when all clients disconnect and the client events task exits. This is likely correct behavior for production but causes issues in tests.

Possible Solutions

1. Modify node behavior: Don't treat client events task exit as fatal when it's expected (e.g., during shutdown)
2. Keep dummy client: Maintain a client connection throughout the test lifetime
3. Graceful shutdown: Modify test structure to properly shutdown nodes before clients disconnect

The subscribe flag fix itself appears to be working correctly - the issue is with test infrastructure.

[AI-assisted debugging and comment]

[sanity]

We won't merge yet, from @iduartgomez:

It won't harm merging it, but is not an optimal solutioon either for an implementation to solve put + subscribe since we need to have a single "committed" (in db parlance) transaction/op for that to work properly, and is not guaranteed to actually subscribe, in fact I think this may lead to race conditions between puts and subscrives. So at this point I don't know if is worth merging this.

[sanity]

[AI-assisted debugging and comment]

CI is still failing with the test_put_with_subscribe_flag test. The test passes locally but fails consistently in CI with 'Node A failed: channel closed'.

Investigation so far:

1. Removed the problematic has_contract() check that was causing potential race conditions
2. Reverted the combinator.rs error handling change to isolate the issue
3. The test still fails, indicating the core issue is with the subscription logic changes in put.rs

The failure appears to be a race condition that only manifests in CI environment. The changes to always run subscription logic when subscribe=true (instead of only when is_seeding_contract) may be triggering this issue.

Next steps to investigate:

• The subscription logic may need additional synchronization
• Could be related to timing of when subscription is started vs when the PUT completes
• May need to make the subscription conditional again or add proper waiting/synchronization

[sanity]

[AI-assisted debugging and comment]

✅ CI is now passing!

Root Cause Analysis

Through systematic debugging, I identified that the call in the new subscription logic was causing node crashes. The issue was a race condition when trying to add self as a subscriber immediately after seeding a contract.

The Fix

Removed the problematic call while keeping the core improvement that allows subscriptions to work on first PUT (not just when the contract is already seeded).

The function already handles subscription registration properly, so the explicit call was both redundant and causing the race condition.

Testing Methodology

1. Added detailed logging to trace execution flow
2. Tested hypothesis that the issue only occurred with freshly-seeded contracts
3. Isolated the problematic code by selectively removing parts of the new logic
4. Confirmed that removing resolved the issue both locally and in CI

Result

• ✅ Test passes locally
• ✅ Test passes in CI
• ✅ All other checks pass (Clippy, Fmt, Build)
• ✅ The intended functionality (subscribe on first PUT) still works correctly

The PR now correctly implements the intended fix without causing node crashes.