[Feature Request] Native execution support for Arch-based environments (CachyOS) / Docker bypass

Is your feature request related to a problem? Please describe. This request is directly relevant to the ongoing Podman migration issue in #1845. Both that effort and the deployment failures documented here share the same root constraint: EMBA's current architecture is tightly coupled to a specific Docker daemon workflow, which blocks alternative container runtimes and native execution paths alike. The findings below may provide useful ground-level diagnostic context for that migration.

On CachyOS (Arch-based), deploying EMBA fails across all tested methods due to hardcoded environmental assumptions:

1. Strict Docker Gatekeeping: The emba wrapper enforces a strict check_docker_dependencies check, halting execution even when all necessary tools (radare2, binwalk, unblob) are installed natively.
2. Absolute Pathing: Even when the local ./external/ directory is successfully populated with dependencies, internal scripts appear to rely on absolute root paths (e.g., /external/cve-bin-tool/...) expecting the official Docker mount structure, causing locally installed tools to go undetected.
3. Package Manager Assumptions: The installer defaults to attempting Homebrew installations on non-Debian systems rather than utilizing the native package manager.

Describe the solution you'd like Official support, or a documented pathway, for native execution bypassing the Docker daemon requirement. Specifically:

1. A --native Execution Flag: A parameter that bypasses check_docker_dependencies and allows EMBA to rely entirely on the host system's $PATH for analysis tools.
2. Dynamic Path Resolution: Updating internal scripts to utilize relative paths (e.g., ./external/ instead of /external/) when running outside the official container, allowing correct discovery of locally compiled binaries.
3. Agnostic Dependency Handling: A documented list of core packages so Arch users can install them via pacman instead of relying on the Ubuntu-focused installer.sh.

Describe alternatives you've considered Several deployment strategies were tested before filing this request, each of which produced diagnostic findings:

• Host Docker Compose (privileged): Ran with --privileged flag. Container built successfully, but execution halted during dependency validation — confirming the issue is not permission-level but architectural: the dependency checks and path assumptions fail regardless of privilege escalation.
• Distrobox (Kali Rolling container): Initialized successfully and apt dependencies were manually resolved inside the container. EMBA execution still failed because the wrapper demanded root Docker privileges within the containerized environment, establishing that the Docker gatekeeping logic does not account for nested or alternative container runtimes.
• Manual Source Patching: Commented out check_docker_dependencies and used the -i flag to isolate whether the failure was in dependency detection or actual dependency absence. Execution progressed further but crashed on the absolute pathing issue, confirming these are two distinct, layered failure points rather than a single surface problem.

Priority issue Are you already a Sponsor? - N

Additional context Note: The two failure points identified here — hardcoded Docker daemon checks and absolute path assumptions — are the same decoupling work that would be required to advance the Podman migration in #1845. This request may be worth considering in that context.

Terminal output observed during native execution after manually resolving apt dependencies inside Kali Distrobox, with Docker checks temporarily patched out. The script reports external directory as missing while simultaneously throwing an absolute path error for a tool present in the local relative directory:

[*] Elementary:
user permission - ok
host distribution - ok
Configuration directory - ok

external directory - not ok
Missing configuration directory for external programs - check your installation
...
python3: can't open file '/external/cve-bin-tool/cve_bin_tool/cli.py':
[Errno 2] No such file or directory
[-] cve-bin-tool database preparation failed - No CVE queries possible