DSOSamenwerkingService::sendAdviesverzoek() has zero production callers — outbound DSO-SWF advice requests may never be sent

[rubenvdlinde]

DSOSamenwerkingService::sendAdviesverzoek() has zero production callers.

What was observed

lib/Service/DSOSamenwerkingService.php:78 —
public function sendAdviesverzoek(array $case, string $partnerOin, string $term, string $dsoSwfUrl, ?string $certPath = null): array.

Surfaced by hydra gate-57 (orphaned-write-capability) during the
openconnector -> integriq app-id rename (#1533). The gate is diff-scoped
under ADR-020, and the rename touched ~100 lib/Service files, which pulled
this method into scope for the first time.

This is pre-existing, not rename damage. Verified on both sides:

• on origin/development: a whole-tree search across lib/, src/ and
  appinfo/ finds no caller;
• on the rename branch: identical.

Why this one is worth a real look

This is not an internal helper. It is an outbound integration: it builds an
adviesverzoek payload from zaak data and POSTs it to a partner organisation's
OIN endpoint over DSO-SWF, optionally with an mTLS client certificate. It
carries @spec openspec/changes/dso-omgevingsloket/tasks.md#task-10, so it was
built against a task that considers this capability delivered.

A fully-implemented, spec'd outbound integration with no caller is precisely the
shape gate-57 was written for — the gate's own docstring cites the shillinq
sweep, where thirteen such capabilities were "done" and unit-tested by calling
the class directly while nothing in production reached any of them.

Suspected consequence

If a municipality is expected to be able to request advice from a partner
organisation through this app, that request is never sent. There would be no
error: no adviesverzoek is built, no HTTP call is made, and nothing logs a
failure, because the code path is simply never entered.

To confirm or dismiss: establish whether the DSO-SWF adviesverzoek flow is
supposed to be reachable from the UI or from a rule/job today.

• If yes, this is a functional gap and the caller needs wiring.
• If it is deliberately ahead of its UI (built for a later milestone), say so on
  this issue and keep it open until the caller lands — an exclude reason
  pointing here already records that.
• If the capability was abandoned, delete the method and its spec task together,
  so the spec stops claiming a delivered capability that no longer exists.

Deliberately not fixed in #1533

#1533 is an app-id rename; wiring or removing an outbound integration is
unrelated behaviour change. The method carries @orphaned-write-capability exclude citing this issue, so the gate does not block the rename while the
finding stays open rather than silenced.