v1.43.0

Proactive audit following #35. v1.42.0 fixed Env; the same trap applied to every other Dockerfile instruction that lands in a container's inspect Config. A container's Config is the image's defaults merged with the user's overrides, with no marker saying which is which — so replicating it wholesale pins the OLD image's values onto the NEW one.

Now filtered against the old image's own Config (genuine user overrides are untouched):

• Labels — image LABELs merged in indistinguishably, so an updated container kept the old org.opencontainers.image.version and went on claiming its previous version (#36).
• Healthcheck — a code comment claimed image-default healthchecks never reach Config.Healthcheck; verified wrong against a live daemon. Self-reinforcing: a new image shipping a repaired healthcheck could never be installed, because the pinned broken one failed the post-update health gate and triggered a rollback.
• User — images re-hardening across versions (root → non-root, changed uid) were forced back onto the old user, causing permission errors.
• WorkingDir / StopSignal — relocated app dirs and changed stop signals were overridden by the old image's values.
• Self-update path — built its run args without the v1.42.0 env filter; now uses the same filter as every other path.

Falls back to the previous behaviour whenever the old image can't be inspected.