diagnostics_channel: fix dangling binding pointer

[TrevorBurnham]

Channel reads its subscriber count through a raw BindingData* that is never cleared, so any native holder that outlives environment cleanup reads a destroyed object. The null check in HasSubscribers() cannot fire, because binding_data_ is only ever assigned in the constructor.

node:sqlite holds a strong BaseObjectPtr<Channel> for the lifetime of a DatabaseSync, which makes this reachable from ordinary JavaScript: a statement left mid-step at exit is finalized by the destructor chain after Environment::RunCleanup() has destroyed the binding, and sqlite3_finalize() invokes the profile callback for such a statement. A release build segfaults at normal process exit; a debug build hits the DCHECK(is_valid()) in AliasedBufferBase::GetValue(). Inside a worker it takes down the whole process.

This clears binding_data_ on every Channel the binding owns whenever it gives up that ownership, both in the destructor and in PrepareForSerialization(), so the existing null check in HasSubscribers() does its job. The second check in Publish() becomes unreachable and is dropped. That protects any holder which is itself a BaseObject, and so is destroyed later in the same cleanup; a holder that is not a BaseObject still needs a cleanup hook or a weak reference, because Realm::~Realm() checks that no BaseObjects remain.

The alternative of giving node:sqlite a cleanup hook, as crypto's FIPS indicator does, leaves the same trap set for the next native holder that forgets it, so the general fix goes in diagnostics_channel.

Two changes go to node:sqlite as well. DatabaseSync::trace_channel_ becomes a BaseObjectWeakPtr, matching the convention permission documents and follows, where BindingData is the sole owner of channels; TraceCallback already null-checks, so that needs no other change. And TraceCallback now tests AreTraceEventsSuppressed() before the channel, so a suppressed callback does not dereference it at all: StatementSync::Finalize() already suppresses trace events, so the reported path was meant to be a no-op, and only the order of the || operands took it through the channel first.

The three changes are independent, and each was checked on its own. With only the weak reference, or with only the reordered condition, the node:sqlite tests pass but the cctest still segfaults, because its holder keeps a strong reference and publishes unsuppressed. With only the diagnostics_channel change, all of them pass. The cctest is therefore what guards that change, and it does so in builds configured --without-sqlite; the node:sqlite test is the user-visible reproduction of the original report, covering the main-thread and worker teardown paths.

Fixes: #65858

[nodejs-github-bot]

Review requested:

• @nodejs/sqlite