chore(docker): use single xcaddy-built Caddy binary (#41808)

## Summary
- Removes the separate "vanilla" Caddy binary download from the base
image
- Always uses the xcaddy-built binary (rate-limit module included; the
module is inert when not configured in the Caddyfile)
- Disables `XCADDY_SETCAP` so the resulting binary stays exec'able under
restricted capability sets

## Motivation
The dual-binary setup existed because the xcaddy-built Caddy failed
`execve` when the container ran with `--cap-drop ALL` (e.g. the
Kubernetes Pod Security Standards `restricted` profile). The previous
workaround was to swap in the upstream vanilla binary when rate limiting
was disabled — but that meant maintaining two binaries with separate
version trains, and customers running rate limiting in restricted-cap
clusters had no good path.

Root cause: the `caddy:builder-alpine` image sets `XCADDY_SETCAP=1`,
which applies `cap_net_bind_service=+ep` as a file capability on the
output binary. Linux refuses to `execve` a file with file capabilities
when the calling process's bounding set doesn't include them — exactly
what `cap-drop ALL` produces. Setting `XCADDY_SETCAP=0` removes the file
capability, and the image already binds low ports via
`net.ipv4.ip_unprivileged_port_start`, so the setcap was unnecessary
anyway.

## Test plan
- [x] Tested in EE deploy preview (ee-9051.dp.appsmith.com) with both
rate-limited and non-rate-limited modes
- [x] Reproduced the original failure against the published image and
confirmed the fix on a CE deploy preview from this branch:
  ```
docker run --cap-drop ALL --sysctl
net.ipv4.ip_unprivileged_port_start=80 \
    --entrypoint /opt/caddy/caddy <image>
  ```
Fails with `operation not permitted` on the current `release` image;
prints the Caddy help banner on this branch.

<!-- This is an auto-generated comment: Cypress test results  -->
> [!WARNING]
> Tests have not run on the HEAD
8c004e79c55077693c9b4691dbb10812564bd71b yet
> <hr>Wed, 27 May 2026 14:15:23 UTC
<!-- end of auto-generated comment: Cypress test results  -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Chores**
* Docker build now supplies a single prebuilt Caddy binary from the
multi-stage image.
* Runtime image no longer performs an in-container download/extract of
Caddy; the binary is provided at image build time.
* Deployment entrypoint simplified to always use the provided Caddy
binary, removing previous conditional selection logic.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/appsmithorg/appsmith/pull/41808?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>