make clean does not remove generated .s files, masking compiler fixes

[mgrossmann]

Summary

`sdk/mklibc.py`'s `compile_c()` only re-runs `cc370 -S` when the `.s` sibling is missing or older than the `.c`:

```python
if os.path.exists(sfile) and os.path.getmtime(cfile) <= os.path.getmtime(sfile):
return None # skip -- .s is up to date

The generated \`.s\` files live next to their \`.c\` in \`src/\` and are gitignored (\`src/*.s\`, \`*.s\`). \`make clean\` only removes \`build/sdk\` -- it does not touch the \`.s\` files in \`src/\`.

## Impact

After fixing a compiler codegen bug (e.g. mvslovers/cc370#14) and reinstalling the fixed \`cc370\`, running \`make clean && make install\` in libc370 silently reused the stale, miscompiled \`.s\` files from before the fix -- because their mtimes were newer than the unchanged \`.c\` sources. The rebuilt \`libc.a\` still contained the old miscompiled object code even though the compiler itself was fixed. This was only caught by inspecting the raw object bytes in the installed archive; nothing in the build output indicated a skip.

Concretely: after fixing mvslovers/cc370#14, \`make clean && make install\` in libc370 did not regenerate \`tm64clck.s\` / \`tm64uclk.s\` / \`tm64mclk.s\` / \`@@tmsecs.s\` etc. because their \`.s\` files (regenerated during an earlier build with the *old* compiler) were newer than the unchanged \`.c\` sources. Only deleting all \`.s\` siblings by hand and rebuilding produced correct object code.

## Suggested fix

\`make clean\` (or a new \`make distclean\`) should also remove every generated \`.s\` that has a \`.c\` sibling in \`src/\`, so a compiler change always propagates on the next clean build. Alternatively, key the staleness check off the compiler binary's mtime (or a version/hash stamp) in addition to the \`.c\` mtime, so a compiler-only fix invalidates existing \`.s\` files without requiring a manual \`rm\`.