Enforce ServerConfiguration bulk and filter limits in the request path

[bdemers]

Summary

The bulkMaxOperations, bulkMaxPayloadSize, and filterMaxResults values on
ServerConfiguration were advertised in /ServiceProviderConfig but never applied to
incoming requests. This change enforces all three in the scim-server request path.

• bulkMaxOperations — BulkResourceImpl.doBulk rejects a request containing more
  operations than the configured limit with HTTP 413 before any operation runs (and before
  the dependency graph is built).
• bulkMaxPayloadSize — BulkPayloadSizeFilter, bound to POST /Bulk by
  BulkPayloadSizeDynamicFeature, wraps the request entity stream in a LimitingInputStream
  that counts bytes as the parser reads them and raises BulkPayloadTooLargeException once
  the limit is exceeded — the body is never buffered. The default is raised from 1024 to
  2097152 bytes.
• filterMaxResults — BaseResourceTypeResourceImpl.find clamps the page-request count
  to the configured ceiling before querying the repository, covering both the GET query and
  POST .search paths. totalResults still reports the real match count.

413 responses carry scimType: "tooMany" and state the maximum, per RFC 7644 section 3.7.4.
The new providers are registered in ScimResourceHelper. The supports* capability flags are
left as advertisements only (no access-control behavior added).

Tests

• Unit tests for each limit: operation-count rejection (with zero side effects), payload-size
  streaming/limit boundaries, the error mapper, and result clamping on both query paths
  including non-default configuration, null/zero/negative counts, and the disabled (<= 0) case.
• ./mvnw clean verify -Pci passes end to end (PMD, SpotBugs, Checkstyle, RAT, and the example
  server integration tests across Jersey, Jersey 4, Quarkus, Spring Boot, and the in-memory
  Testcontainers ContainerIT).