knowledge(error-handling): a bare [TryFunction] call propagates its error

The review agent repeatedly flagged bare calls to [TryFunction] procedures
(e.g. the System Application "Xml Validation" Try* APIs) as defects,
including claims that the failure is "silently swallowed". A bare call is
an ordinary call: the error propagates as usual.

- Add negative knowledge bare-tryfunction-call-propagates-errors.md.
- Narrow ignored-tryfunction-return-disables-try-semantics to code that
  visibly expects the failure to be caught; the bad sample now shows that
  in code, and the good sample includes an intentional bare call as the
  clean control.
- Qualify "TryFunction catches all errors" in the events article and the
  "must be consumed" wording in the performance article.
- Error-handling leaf worklists both articles for bare [TryFunction] calls
  and requires the same evidence before flagging.
- Add the three paired articles to the evaluation overrides.

microsoft/knowledge/events/avoid-raising-events-inside-try-functions.md

@@ -11,7 +11,7 @@ application-area: [all]
 
 ## Description
 
-A `TryFunction` catches all errors — including errors thrown by event subscribers. When an `[IntegrationEvent]` is raised inside a `TryFunction` body, any error a subscriber raises is silently swallowed by the TryFunction's error boundary. The subscriber's logic fails, the caller sees no error, and the calling code continues as if nothing happened. Subscribers have no way to signal failure to the caller.
+A `TryFunction` whose caller consumes its Boolean result catches all errors raised during its execution — including errors thrown by event subscribers. When an `[IntegrationEvent]` is raised inside a `TryFunction` body, any error a subscriber raises is silently swallowed by the TryFunction's error boundary. The subscriber's logic fails, the caller sees no error, and the calling code continues as if nothing happened. Subscribers have no way to signal failure to the caller.
 
 ## Best Practice