IntegrationList: /setting/integrations ignores fields projection for branded integration types

[rdmarsh]

Summary

GET /santaba/rest/setting/integrations (the IntegrationList endpoint) only
partially honors the fields query parameter. For generic integration types
(http, email) the projection works and only the requested fields are
returned. For branded integration types (servicenow, msTeams, slack-2,
connectwise-2, ...) the fields parameter is silently ignored and the API
returns the full type-specific object (~100+ fields) regardless.

Because the projection is applied per-record within a single response, the same
request returns some records trimmed to the requested fields and others fully
expanded — which makes the behaviour look intermittent until you correlate it
with type.

Environment

• LogicMonitor REST API, /santaba/rest/setting/integrations
• Observed via the (unofficial) elm CLI, which sends the documented
  fields= query parameter; confirmed the parameter is present and correctly
  formed in the outgoing request URL.

Steps to reproduce

Request the integration list projecting just three fields, including type:

GET /santaba/rest/setting/integrations?fields=id,name,type&size=0

Then group the returned items by type and count, for each type, how many
records came back with exactly the 3 requested fields vs the full object:

# acme = your account; this prints only type names + counts, no integration data
elm --config /path/to/acme.ini IntegrationList -f id,name,type --size 0 \
  | jq -r '.IntegrationList
      | "total: \(length)",
        (group_by(.type)[]
          | "\(.[0].type // "(none)"): total=\(length) projected_ok=\([.[]|select((keys|length)==3)]|length) full_object=\([.[]|select((keys|length)>3)]|length)")'

Expected

fields=id,name,type returns only id, name, and type for every
record, regardless of integration type.

Actual

projected_ok (only the 3 requested fields) for generic types; full_object
(all ~100+ fields) for branded types. Observed consistently across three
independent portals:

type	fields honored?
http	yes
email	yes
servicenow	no — full object
msTeams	no — full object
slack-2	no — full object
connectwise-2	no — full object

Every branded type tested ignored fields; no counter-examples. The pattern is
fully correlated with type, suggesting the branded-integration serializers
bypass the generic field-projection path.

Impact

• Callers cannot reduce payload size or avoid pulling sensitive fields (the full
  object includes credentials/secrets fields, even if masked) when branded
  integrations are present.
• Field projection cannot be relied on for /setting/integrations; callers must
  project client-side as a workaround.

Workaround

Project client-side after fetching the full response, e.g.:

elm IntegrationList --size 0 -f json | jq '[.IntegrationList[] | {id, name, type}]'

Notes

• This is not an elm bug: elm sends fields= correctly and performs no
  client-side projection (it renders exactly what the API returns).
• Related to but distinct from LM swagger missing standard query params on multiple endpoints #47: LM swagger missing standard query params on multiple endpoints #47 covers query params missing from the
  swagger spec; this issue is about a param that is present and accepted but
  selectively ignored at runtime.
• Per project convention this stays open until LogicMonitor fixes the API; a
  client-side workaround does not close it.