STO-446: feat(model): add --delete-my-model-files-after-upload

[jebenexer]

Fixes STO-446.

model add --model-path uploads whatever files are currently in the directory, with no tracking of what belonged to a previous version. Reusing the same local directory across model versions silently uploads a contaminated mixture of old and new files.

Fix

New opt-in flag: --delete-my-model-files-after-upload.

• Requires --model-path and --wait-for-hash — errors immediately (before any upload) if either is missing.
• Deletes only the exact files uploaded by this run, and only after the model version hash is confirmed server-side. Never a blanket directory wipe.
• If hash confirmation or any file deletion fails, the command exits non-zero and leaves files in place — no silent partial success.
• Adds deletedModelFiles/deletedModelFilesBytes to JSON output.

Testing

• New unit tests covering flag validation, the happy path (verified deletion + output), and both failure modes (hash-confirmation failure leaves files untouched; partial delete failure reports non-zero with the specific failing file).
• Full existing test suite passes.
• Validated end-to-end against a local RIAB stack (real GraphQL + S3-backed upload + hasher pipeline, not mocks):
  • Reproduced the original contamination bug: uploading model B into a directory still holding model A's config.json silently included it — confirmed by downloading the file and seeing model A's content.
  • Confirmed the fix leaves the directory clean after a verified upload.
  • Confirmed the hash-timeout failure path leaves files untouched with a non-zero exit.
  • Round-trip integrity check: uploaded a 4-file model (including a nested subdirectory) with the new flag, captured SHA-256 hashes of the originals before upload, let the flag delete the local copies, then re-downloaded all 4 files through mProxy's presigned S3 URLs and diffed hashes. All 4 files were byte-identical to the originals — confirms the server-side stored blobs are correct before the local copies are removed, not just trusted based on the upload response.

Follow-up (not in this PR)

The runpodctl skill and vendored command-surface.json in runpod/runpod-plugins-official are both tied to released versions — will update those once this ships in a release.

[promptless]

Promptless documentation updates

• Document runpodctl model commands, model-remove endpoint safety, and serverless update model flags documents this change in the runpodctl CLI reference. Docs PR