Misleading warning when a wrapper checkout is dirty: 'does not match locked hash <same hash>'

[dboreham]

Building a wrapped container against a wrapper repo checkout that has uncommitted
changes warns like this:

WARN: wrapper static-content at 05018a32b076dfd304eb90c522435306371698cb does not match locked hash 05018a32b076dfd304eb90c522435306371698cb.

The same hash on both sides of "does not match". The build is doing the right thing —
the checkout has local modifications, so it deviates from the lock and the image gets a
stackdev- tag — but the message names the one property that is identical and says
nothing about the one that differs.

src/stack/build/build_containers.py:574:

elif wrapper_used["dirty"] or (
        wrapper_used["hash"] and wrapper_used["hash"] != identity.wrapper_pin.get("hash")):
    log_warn(f"WARN: wrapper {wrapper_used['name']} at {wrapper_used['hash']} "
             f"does not match locked hash {identity.wrapper_pin.get('hash')}.", bold=True)

The condition covers two cases and the message only describes the second. The dirty case
wants its own wording — something naming local modifications as the reason, as the
deviating_inputs entry already does with its -dirty suffix, and as the separate
"wrapper repo for static-content has local modifications, not locking" message does later
in the same build.

The payload equivalent a few lines above (:541) compares versions rather than a
dirty flag, so it does not have this problem.

Found while adding authentication to the static-content wrapper; cosmetic, no effect on
what gets built or tagged.