Propagate saveClassID error and clear stale classid files

[sjmiller609]

Summary

Follow-up to #179. Addresses two review comments on the tc class collision fix:

• saveClassID now returns error instead of discarding it with _ =. If the write fails (e.g. disk full), the error surfaces immediately rather than silently losing the collision-resolved class ID — which would cause removeVMClass to fall back to deriveClassID and target the wrong class.

• Stale classid files are cleared when no upload rate limiting is applied (classID is empty). Previously, if an instance was recreated without rate limiting, the old classid file persisted, causing ReleaseAllocation to delete the wrong tc class.

Changes

• lib/network/allocate.go — saveClassID returns error; callers propagate it; new clearClassID helper; both CreateAllocation and RecreateAllocation clear stale files when classID is empty.

---

Note

Medium Risk
Touches network allocation/restore paths by changing saveClassID to fail fast on disk write errors and by deleting persisted class IDs when no rate limiting is applied, which could surface new allocation failures and affects tc class cleanup behavior.

Overview
Improves tc class ID persistence during network allocation/restore by making saveClassID return an error and propagating failures from CreateAllocation/RecreateAllocation instead of silently ignoring write issues.

Also clears any existing classid file when createTAPDevice returns an empty class ID (no rate limiting), preventing stale persisted IDs from causing incorrect tc class deletion on release.

^{Written by Cursor Bugbot for commit b0ec2e4. This will update automatically on new commits. Configure here.}