fix(typeck): reject non-path receivers for Vector/Mapping storage ops

[mohammadfawaz]

Summary

• Vector::{len,get,set,push,pop,swap_remove,clear} and Mapping::{get,get_or_use,contains,set,remove} assume an Expression::Path receiver downstream (storage_lowering for vectors, codegen for mappings), but type-checking only verified the receiver's type.
• Read ops had no path check, so a ternary of two storage vectors ICEd in storage_lowering and a ternary of two mappings produced invalid bytecode that failed late at disassembly.
• Write ops already had an is_local_path check, but emitted the "external vectors/mappings" diagnostic for a local ternary receiver, which is misleading.
• Add an Expression::Path pre-check to all eleven arms and emit a new ETYC0372191. The existing "external" diagnostic now only fires when the receiver is an actual external path.

Fixes #29428.

[mitchmindtree]

Left one optional suggestion, but lgtm!

[mitchmindtree]

Looks like quite a few of these - I wonder we'd benefit from something like:

  /// Returns `true` if `expr` is a path receiver; otherwise emits a diagnostic and returns `false`.
  fn check_path_receiver(&self, module: &str, operation: &str, kind: &str, expr: &Expression) -> bool {
      if matches!(expr, Expression::Path(_)) {
          return true;
      }
      self.emit_err(crate::errors::type_checker::storage_op_requires_path_receiver(
          module, operation, kind, expr.span(),
      ));
      false
  }

[mohammadfawaz]

Good call, done. Extracted into a check_path_receiver helper.

[codspeed-hq]

Merging this PR will not alter performance

✅ 17 untouched benchmarks

---

_{Comparing fix/29428-ternary-storage-receiver (a9bc243) with master (33008b2)¹}

Footnotes

1. No successful run was found on master (3a6eba3) during the generation of this report, so 33008b2 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩