Always include a requested activation in the connection PATCH

[ZayanKhan-12]

Fixes #97

Root cause

Exactly as suspected in the issue discussion: the UPDATE case in dataProvider.js builds the PATCH body from deep-diff(previousData.$staged, data.$staged). The activation object in an IS-05 PATCH is a request, not staged state — but when a receiver's staged endpoint already reports the same activation values (e.g. a node that initializes staged activation.mode to "activate_immediate", as in the reporter's setup), the diff contains no activation entries, so the Connect tab's Activate button and Staged/Edit immediate activation send a PATCH with no activation object, and nothing activates.

Minimal repro of the mechanism (deep-diff 1.0.2, same as the lockfile):

const diff = require('deep-diff');
const prev = { activation: { mode: 'activate_immediate', requested_time: null }, master_enable: true };
const next = { activation: { mode: 'activate_immediate', requested_time: null }, master_enable: true, sender_id: 'abc' };
diff(prev, next); // => [{ kind: 'N', path: ['sender_id'], rhs: 'abc' }] — activation gone

Fix

After building patchData from the differences, include data.$staged.activation whenever its mode is non-null. A null mode is deliberately not force-included: it is still only sent when it results from an actual difference, so pending scheduled activations are not unintentionally cancelled by unrelated edits.

Verification

• yarn lint-check clean
• yarn build succeeds (production build)
• the repro above plus manual tracing of both affected paths (makeConnection.js Connect-tab activation and Staged/Edit) — both now always carry activation in the PATCH body when a mode is chosen

🤖 Generated with Claude Code

[garethsb]

As pointed out in #97, the bug is in the Receiver in that case, not nmos-js, so needs further discussion about whether to include this workaround in nmos-js.

[garethsb]

I think by expanding the comment slightly, the rationale is a bit clearer. Then, seems OK to me. Thanks for the contribution.

[garethsb]

Suggested change

	// the activation object in a PATCH requests an activation, rather
	// than reflecting staged state, so when a mode is set, include it
	// even if the staged endpoint already reported the same values,
	// which otherwise leaves it out of the differences (see #97)
	// Activation in a PATCH is a request, not staged state. Include it whenever
	// the request has a non-null mode, even if GET /staged already reported the
	// same values (otherwise deep-diff omits it). That also covers non-conformant
	// devices that leave activate_immediate on /staged (see #97). A null mode is
	// only sent when it appears in the differences, so unrelated edits do not
	// cancel a pending activation.

[ZayanKhan-12]

Thanks for the review @garethsb — I've applied your suggested comment wording verbatim in 6a391cc. I also ran the full controller test suite locally (IS-04-04, IS-05-03 and BCP-007-03-02 via the Testing Façade against the AMWA testing tool) and all three suites pass with this change.