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.

.gitea/workflows/ci.yml

@@ -61,6 +61,16 @@ jobs:
       # --no-run: the workflow compiled every test target without running them,
       # which catches a test that no longer builds without paying for the suite.
       - run: cargo test --workspace --locked --no-run
+      # The release profile, on main only. It is the profile the image is
+      # built with, and it fails in ways the dev profile does not: v2026.9.24
+      # was tagged on a commit whose CI was green and whose release build
+      # could not compile the scim crate at all. A few minutes per merge is
+      # cheaper than finding that out from a tag, which throws away a
+      # multi-architecture build and leaves a version half-cut.
+      #
+      # Pull requests stay on the dev profile, where the wait is worth less.
+      - if: github.event_name == 'push'
+        run: cargo build -p inbuxa --locked --release
       # Keep the cache from growing without bound: past 60 GB the target dir
       # is dropped and the next build starts cold. The download cache stays.
       # Two builds (dev + test profiles) already fill ~22 GB, so the limit