--podman-build-args breaks CLI argument precedence over compose.yaml

**Describe the bug**

Build arguments defined inside the `--podman-build-args` flag do not maintain proper CLI precedence over build arguments defined in `compose.yaml`. The parameters passed via `--podman-build-args` are appended before the ones evaluated from `compose.yaml`, causing the `compose.yaml` values to override the CLI values (since the last flag wins in Podman/Docker CLI evaluation).

**To Reproduce**
Steps to reproduce the behavior:
1. Define a `compose.yaml` with a build argument set to 0:
```
services:
app:
build:
context: .
args:
CUSTOM_VAR: 0
```
2. Run `podman-compose` overriding the argument via `--podman-build-args`:
`podman-compose --podman-build-args="--build-arg CUSTOM_VAR=1" build`

3. Observe the underlying `podman` build command generated and executed by `podman-compose`:
`podman build --build-arg CUSTOM_VAR=1 --build-arg CUSTOM_VAR=0 .`
Here, `CUSTOM_VAR=1` (from CLI) is litterally placed before `CUSTOM_VAR=0` (from `compose.yaml`) without being evaluated. As a result, `CUSTOM_VAR=0` overrides `CUSTOM_VAR=1`, effectively violating the expected CLI > `compose.yaml` precedence.

4. Run `podman-compose` using the argument `--build-arg`:
`podman-compose build --build-arg CUSTOM_VAR=1`

5. The output is correctly evaluated:
`podman build --build-arg CUSTOM_VAR=1 .`

**Expected behavior**
The precedence hierarchy for build arguments should consistently be:
- CLI Flags (Highest priority)
- `compose.yaml / docker-compose.yml`
- Dockerfile / Containerfile (Lowest priority)

Any `--build-arg` supplied via the CLI (whether passed directly or encapsulated via `--podman-build-args`) should take precedence over values defined inside the `compose.yaml` file.

**Actual behavior**
When passing a build argument using `--podman-build-args="--build-arg VAR=val"`, podman-compose injects the flag early into the generated podman build command. It then appends the arguments parsed from `compose.yaml` after it.

Since `Podman` evaluates multiple `--build-arg` declarations sequentially and applies the last one, the value from `compose.yaml` wins over the CLI value provided inside `--podman-build-args`.

*MAYBE* this probably affects also other evaluation topics like the one reported here: https://github.com/containers/podman-compose/issues/1174

Start by reproducing the issue with compose.yaml and the podman-compose build command shown in the report, then trace the build-command construction and argument ordering. The fix is done when --podman-build-args values appear after compose.yaml build arguments so they take precedence, with a regression test covering CUSTOM_VAR=1 over CUSTOM_VAR=0.

Written by the indexing model from the issue text.