Honor explicit inactive_threshold of 0 in KV watch

[caspervonb]

watch() used a truthiness check on inactive_threshold, so an explicit 0 (disable the inactivity cleanup) was indistinguishable from None and got overridden with the 5 minute default. Check against None.

Fixes #580.

[synadia-claude-reviewer]

Claude finished @caspervonb's task in 2m 2s —— View job

---

PR Review

• Gather context and understand the request
• Review PR changes (gh pr diff 991)
• Examine relevant source files for context
• Post review findings

---

Summary

The fix in kv.py is correct and minimal. The root cause was a truthiness check (if not inactive_threshold:) treating 0 and None identically; replacing it with if inactive_threshold is None: resolves that cleanly.

Findings

1. Related unfixed bug in client.py:432 (not in diff, but surfaced by this change)

# nats/src/nats/js/client.py:432
if inactive_threshold:
    config.inactive_threshold = inactive_threshold

This is the same truthiness-check pattern. If a caller uses js.subscribe(inactive_threshold=0) directly, this silently drops the value. For the specific kv.watch(inactive_threshold=0) path fixed here it doesn't cause a regression — because _to_nanoseconds(None) and _to_nanoseconds(0) both produce 0 on the wire — but it's an inconsistency. Should be:

if inactive_threshold is not None:
    config.inactive_threshold = inactive_threshold

2. Weak test assertion

# test_js.py
assert info.config.inactive_threshold < 5 * 60

This verifies the old bug (forced 300s) is gone, but not what value the server actually applied. Given the comment says "An explicit 0 disables the inactivity cleanup so the watch runs forever", asserting < 5 * 60 is the right check for a regression guard, but the comment in code is slightly misleading — passing 0 means "let the server decide its minimum", not literally forever. Minor documentation nit.

3. No correctness or security issues. The change is safe and the test covers the regression case.