Twelve W1xxx codes are declared and emitted nowhere, including three that hide real mistakes

Vx#434 audited the E6xxx codes and found one that was declared with no emission site (E6002). The
same sweep over the W1xxx codes finds twelve of twenty-three. Each appears exactly once in the
tree, at its own declaration in src/diagnostic.rs; nothing can produce it.

The other eleven (W1001, W1003, W1009, W1024-W1031) are emitted and mostly tested.

Three of them are not hygiene

W1014 -- narrowing cast loses precision. The value is silently mangled:

let big : i32 = 100000;
let small = big as i8;
print(small);          // prints -96, no diagnostic

This sits in the area Vx#240 settled: as is the explicit conversion, and the point of making it
explicit is that the programmer is asked to mean it. A narrowing that discards the value silently
gives the cast the appearance of a checked operation without the check.

W1022 -- transfer to the space the value is already in. A no-op transfer compiles silently:

let t = Tensor<f32, [4, 4]>::uninit();   // already CPU_DRAM
let _s = transfer(t, Memory::CPU_DRAM);  // no diagnostic

A transfer that moves nothing is a modelling mistake, and it is the kind that survives a refactor:
the space names stay in the source while the value's actual location changes underneath them.

W1023 -- spawn on Topology::Current. A spawn that does not spawn compiles silently. In a language
whose claim is that placement is declared and checked, a placement annotation that is a no-op is
exactly the thing the reader would want flagged.

Why this matters more than the count suggests

A declared code with no emission site is not a missing feature, it is a claim the compiler makes in
its own diagnostic table and does not keep. Anything that reads the taxonomy -- documentation, a
paper's error table, a user grepping for what the compiler checks -- is reading a list of promises,
twelve of which are unbacked.

Related: Vx#443, where a shadowed placement silently loses bytes from the working set. W1005 would at
least have made the construct visible there. It would not have made the accounting correct, so that
issue still needs its own fix.

Suggested order

1. W1014, W1022, W1023 -- each hides a real mistake and each is cheap to emit at a site that already
   has the information.
2. The rest, or delete the codes that nobody intends to implement. A code deleted from the table is
   honest; a code sitting in the table unemitted is not.

Every one of the twelve was confirmed dead by grep and the first five by running a program that
should trigger them.

Start in src/diagnostic.rs and use the issue's grep results to inspect W1014, W1022, and W1023 first. Run the triggering programs described in the issue, then trace the existing cast, transfer, and spawn entry points. Done means each intended warning is emitted and tested, or any code not planned for implementation is removed from the diagnostic table.