fix(selfdev): keep embedded git hash in lockstep with HEAD via dev_cargo env export

The self-dev publish guard rejects a freshly built binary when its embedded
git hash lags HEAD ('binary was built from git hash X, but source state is Y'),
forcing a manual 'touch Cargo.toml' workaround after every commit.

Root cause: jcode-build-meta/build.rs intentionally does NOT watch .git/HEAD or
.git/index as rerun-if-changed inputs (their mtimes change on every git add/
status/commit, which would force a full base->app-core->tui->cli recompile on
each incremental build). So after a commit the binary keeps embedding the prior
short hash.

Fix: dev_cargo.sh now exports JCODE_BUILD_GIT_HASH (and _DATE) from the current
HEAD. build.rs already declares cargo:rerun-if-env-changed for both, so cargo
reruns the build script ONLY when the value changes -- i.e. exactly when HEAD
moves -- and never on a bare git add/status or repeated builds on the same
commit. This embeds the correct hash after every commit while keeping
same-commit incremental builds fully incremental.

We deliberately do not export JCODE_BUILD_GIT_DIRTY (it flips on every edit and
would reintroduce per-build churn); dirty builds are validated by the publish
guard via source fingerprint / mtime, not the embedded flag. The remote build
path is unaffected: it injects metadata via .jcode-build-meta and already
captures the correct hash.

Verified: changing the env hash reruns build-meta; an unchanged hash does not;
the emitted JCODE_GIT_HASH and the built binary's 'version --json' both match
HEAD. All 15 jcode-build-support tests pass.