Compile the scim crate in release, and check that profile in CI

v2026.9.24 was tagged on a commit CI had passed, and its release build could
not compile crates/scim at all:

  error: queries overflow the depth limit!
    = note: query depth increased by 130 when computing layout of
      {async fn body of context::<impl ...>::writable_domain()}

The crate is ours, and the failure is profile-dependent: the release profile
computes those async fn layouts in one go and goes past rustc's default query
depth, while the dev profile never gets that far. CI builds dev, so CI was
green on a commit that could not be released. The tag produced no image and
no release, which is the one merciful part.

Two changes:

- #![recursion_limit = "256"] on the crate, which is what rustc itself
  suggests, with a note saying why it only shows up in release. Proved by
  building -p scim in release locally: it now finishes.

- CI builds the release profile too, on pushes to main. Pull requests stay
  on dev, where the wait is worth less. A few minutes per merge is cheaper
  than learning this from a tag, which throws away a multi-architecture
  build and leaves a version half-cut.

crates/scim/src/lib.rs

@@ -4,6 +4,14 @@
  * SPDX-License-Identifier: AGPL-3.0-only
  */
 
+// The release profile computes the layout of this crate's async fn bodies in
+// one go, and the deepest of them -- writable_domain, which awaits through
+// the directory, the store and the JMAP registry -- takes rustc past its
+// default query depth. The dev profile does not get that far, so the failure
+// only appears in a release build: CI was green and the tag that started a
+// release was not.
+#![recursion_limit = "256"]
+
 //! SCIM 2.0 provisioning (`docs/spec/features/scim.md`). inbuxa-server is the
 //! service provider: an identity provider pushes users and groups to
 //! `/scim/v2`, and each request becomes the same `x:Account` reads and