Vec has no drop: free() is manual, and TYPE_NEEDS_DROP is reserved but never set

Noted while answering how one allocates a growable container. Vec<T> (stdlib/std/vec.vx) is the std::vector analogue -- { data: *mut T, len: i32, capacity: i32 }, doubling growth through vx_vec_grow with the byte-size math overflow-checked in Rust -- and it works: a program that pushes, gets, sets and sums runs correctly on the flat path through the JIT.

What it does not have is a destructor. free() is a method the programmer calls:

let mut v : Vec<i32> = Vec<i32>::new();
v.push(10);
v.free();          // required; nothing calls it for you

Consequences today:

• a Vec that goes out of scope leaks,
• a double free() is not caught,
• free() after a move is not caught.

There is a TYPE_NEEDS_DROP bit reserved at src/gid.rs:51, in word 3 of the TypeId where it would participate in type identity. Nothing sets it -- the only references in the tree are its definition and one unit test asserting the bit round-trips. So the mechanism is reserved and unimplemented rather than partially wired.

Filing as the tracking point for the decision: whether Vx gets scope-based drop (the bit exists for it), or stays explicit-free with the linear-type checker made to catch use-after-free and double-free, which is the cheaper half and would close the silent cases. Vec::free already zeroes data/len/capacity, so a double free is currently a no-op rather than a crash -- which hides it.

Related: Vx#487 (iter.vx does not type-check standalone), which is the iterator surface over the same container.

Start with stdlib/std/vec.vx and src/gid.rs:51, then inspect the unit test that checks TYPE_NEEDS_DROP round-tripping. Compare the scope-based drop and explicit-free alternatives described in the issue, including the linear-type checker and related iterator issue Vx#487. Done requires an agreed ownership model and implementation of its safety checks.