SendQuery notification nesting leak on query veto

[bero]

Problem

TBoldPublisher.SendQuery calls StartNotify but exits early without calling EndNotify when a subscriber vetoes (returns False). This permanently increments the global G_NotificationNesting counter, preventing the post-notification queue from ever being drained.

Impact

Every vetoed query leaks one nesting level. After even a single veto, DelayTillAfterNotification actions (subscription packing, deferred updates) are queued but never executed.
Over time this causes:

• Unbounded growth of the post-notification queue
• Subscription arrays never getting packed (memory waste)
• Any deferred logic silently dropped

Root Cause

// BoldSubscription.pas - TBoldPublisher.SendQuery
StartNotify;
for I := ... do
  if not Subscriber.Answer(...) then
  begin
    Result := False;
    Exit;        // ← exits without EndNotify
  end;
EndNotify;       // ← only reached if no veto

Fix
Wrap StartNotify/EndNotify in try/finally, matching the pattern already used in CancelAllSubscriptions and CancelSubscriptionTo.

StartNotify;
try
  for I := ... do
    if not Subscriber.Answer(...) then
    begin
      Result := False;
      Exit;
    end;
finally
  EndNotify;
end;

New unit tests for BoldSubscription.pas — TestQueryVetoPattern left the nesting counter at 1, causing TestDelayTillAfterNotification to fail.