[kenny-ish]

Closes #1519

Summary

withEnvironment merged the new variables into this.environment but appended them to createOpts.Env. Setting a key twice sent both entries to Docker:

new GenericContainer(image).withEnvironment({ A: "1" }).withEnvironment({ A: "2" });
// createOpts.Env: ["A=1", "A=2"]

The process saw A=2, so this was mostly invisible, but docker inspect showed the stale A=1, the reuse hash differed from a container configured with { A: "2" } once, and a subclass that needs to change a variable had to filter createOpts.Env by hand (the REDIS_ARGS workaround in RedisContainer.start()).

createOpts.Env is now built from the merged this.environment, so it holds one entry per key and the last value wins, matching what the container already saw at runtime. The Redis workaround keeps working unchanged and is already being removed with the Redis Stack code in #1597, so this PR does not touch it.

The containers doc gets one line saying that repeated withEnvironment calls add to the variables and that setting a key again replaces its value.

Verification

• npm run lint:ci, npm run knip, npm run check-compiles
• mkdocs build --strict
• npx vitest run packages/testcontainers/src/generic-container/generic-container.test.ts

New case in generic-container.test.ts, should replace an environment variable that is set twice: sets customKey twice and otherKey once, starts the container, and checks through inspect() that Config.Env has exactly one customKey=second entry and still has otherKey=otherValue, and through the test image's /env endpoint that the process sees second.

• Red (pre-fix generic-container.ts): 1 failed, Config.Env contained both customKey=first and customKey=second.
• Green: the new case and the rest of the file pass.

Not breaking

No public API change. A key set once produces the same Env entry as before. A key set more than once now produces one entry with its final value, which is the value the container process already received.