Podman Support Issues in install.sh

### Self-Hosted Version

26.5.1

### CPU Architecture

x86_64

### Docker Version

N/A (using Podman 4.9.3)

### Docker Compose Version

NA (using Podman Compose 1.5.0)

### Machine Specification

- [x] My system meets the minimum system requirements of Sentry

### Installation Type

Fresh Install

### Steps to Reproduce

1. Install podman and podman-compose (not docker)
2. Run ./install.sh

### Expected Result

install.sh detects podman and proceeds

### Actual Result

Running self-hosted 26.5.1 with Podman 4.9.3 + podman-compose 1.5.0 (no Docker installed) revealed several blocking issues:
1. Container engine detection has no podman fallback
install/_detect-container-engine.sh only selects podman if CONTAINER_ENGINE_PODMAN=1 is set. Otherwise, it falls through to the docker check and fails with FAIL: Neither podman nor docker is installed on the system. even when podman is on PATH.
Fix: Add an elif command -v podman fallback before the error.
2. dc-detect-version.sh unconditionally overrides CONTAINER_ENGINE
install/dc-detect-version.sh:11 always sets export CONTAINER_ENGINE="docker", discarding whatever was detected in step 1. If CONTAINER_ENGINE_PODMAN is not 1, it then checks for docker compose / docker-compose (which don't exist) and fails with FAIL: Docker|Podman Compose is required to run self-hosted.
Fix: Only default to docker if CONTAINER_ENGINE is not already set.
3. Podman-compose doesn't read COMPOSE_PROFILES from --env-file
bootstrap-s3-profiles.sh calls start_service_and_wait_ready vroom, but vroom is behind profiles: feature-complete in docker-compose.yml. Docker Compose reads COMPOSE_PROFILES=feature-complete from the env file and auto-activates the profile. Podman-compose 1.5.0 does not, resulting in WARNING: podman_compose: missing services [vroom].
Fix: Pass --profile=feature-complete explicitly to $dc up in the podman branch of start_service_and_wait_ready.
4. Pod creation inconsistency between $dc up and $dcr
start_service_and_wait_ready calls $dc up (creates pods by default), but $dcr uses --in-pod=false. Later, $dcr web upgrade --create-kafka-topics fails because dependency containers exist inside pods while the run container is outside:
Error: container dependency is part of a pod, but container is not: invalid argument
Fix: Add --in-pod=false to the $dc variable itself for podman, so all compose commands are consistent.
5. up --wait not supported by podman-compose
The install success hint prints podman compose ... up --wait, but podman-compose 1.5.0 does not support --wait. This requires up --force-recreate -d instead.
6. Podman needs docker.io as an unqualified search registry
Fresh podman installations have no unqualified-search-registries set in /etc/containers/registries.conf, causing failures like:
Error: creating build container: short-name "altinity/clickhouse-server:25.3.6.10034.altinitystable" did not resolve to an alias and no unqualified-search registries are defined
Mitigation: User must add unqualified-search-registries = ["docker.io"] to their registries config. (This is a podman configuration concern, but the install script could detect and warn.)

### Event ID

_No response_

Start with install/_detect-container-engine.sh and install/dc-detect-version.sh, then trace bootstrap-s3-profiles.sh and start_service_and_wait_ready in the install flow. Reproduce a fresh install using Podman 4.9.3 and podman-compose 1.5.0, checking engine detection, profile activation, pod consistency, the success hint, and registry warning behavior; done means the listed blocking failures no longer occur.

Written by the indexing model from the issue text.