feat(runtime): add HashMap.entries() -> Vec<(K, V)>

[gertybotbot]

Closes #2414.

Implements the remaining additive slice of the collection remove/sentinel reshape:
HashMap.entries() returning an owned Vec<(K, V)>.

Implementation

Wiring spans the full stack:

• Checker — dispatch, admissibility, and method resolution for entries().
• MIR — lowering facts and runtime symbol registration.
• Codegen — layout, llvm, and runtime ABI.
• Runtime — hew_hashmap_entries_layout clones each key/value pair into a tuple
  element and transfers ownership into the result vector.

Proof bar

The issue asked for three things; each is covered:

1. Execution coverage — tests/hew/hashmap_entries.hew plus additions to
   hew-codegen-rs/tests/exec/hashmap_keys_values_exec.rs.
2. Owned-allocation balance — hew-runtime/tests/hashmap_entries_owned_balance.rs
   asserts allocations == frees across map ingress, the entries clone, map free,
   and vec free.
3. Leak detection under ASan — tests/vertical-slice/accept/hashmap_entries_asan.hew
   wired into scripts/asan-fixture-check.sh.

The balance test is load-bearing (verified by actual revert)

Reverting the ownership transfer so an extra owned clone escapes produces
6 allocations against 4 frees and fails the assertion:

assertion `left == right` failed: every owned entries allocation must be released
  left: 4
 right: 6

Scope note for reviewers: those counters instrument the test's own owned payloads,
so the test targets element-ownership balance. A leak of the runtime's internal
scratch buffer is outside its window — that case is what the ASan fixture covers.

Verification

• cargo test -p hew-runtime --lib — 2240 passed, run 3x.
• cargo test -p hew-types — all suites green (1748 + 339 + 282 + 232 + 125 + 72 + 22 + 8).
• Rebased on main at the time of submission.

One flaky failure was observed in
transport::tests::framed_send_to_broken_pipe_fails_closed_without_signal (a
broken-pipe/signal-timing test unrelated to this change). It was not reproducible:
the full lib suite passes 2240/2240 on this branch across three consecutive runs, and
the test passes in isolation on both this branch and the pristine base.

[gertybotbot]

The nine clippy: unsafe block missing a safety comment code-scanning findings on this PR are stale and do not reflect the current head.

They were raised against the original feature commit 38cd1955 (original_commit_id on every one of the nine comments). The follow-up commit 4445a95f style(runtime): document entries() unsafe blocks added the missing // SAFETY: comments, and it is in this PR's history — it is in fact the merge-base of the current head f8c203dc.

Verified directly against the pushed head, all nine flagged lines (1803, 1805, 1808, 1820, 1830, 1836, 1842, 1844, 1850) carry a preceding // SAFETY: comment:

git show f8c203dc:hew-runtime/src/hashmap.rs

hashmap.rs goes from 143 SAFETY: comments at 38cd1955 to 152 at the head. Line 1850 is the multi-line unsafe { … } block documented by the five-line comment at 1845–1849.

No code change is needed; the alerts should clear or be dismissed as fixed. Flagging so the review isn't held up by phantom findings — CI is 9/9 green and the PR is MERGEABLE.