Fix RestClient checkpoint listing and publish/unpublish against Logit…

[w-angxu]

…s backend

The Logits backend diverged from the upstream Tinker schema/routes:

• Checkpoint objects are returned with logits_path / size / visibility / expired_at, but the upstream Checkpoint model requires tinker_path and uses size_bytes / public / expires_at. list_checkpoints / list_user_checkpoints therefore raised APIResponseValidationError. Parse the backend's real field names via _BackendCheckpoint and translate back to the upstream Checkpoint type so callers keep the documented shape.

• The publish/unpublish routes accept only the opaque chk_... checkpoint id, but the logits_path the backend advertises (and that save_state returns) embeds the human-readable checkpoint name. Resolve name -> checkpoint_id via the run's checkpoint list before calling publish (POST) / unpublish (DELETE).

Verified end-to-end against api.logits.dev: list_checkpoints, publish and unpublish now work with the documented logits://<run>/weights/<name> paths. Adds unit tests for the field translation.

📋 PR Title Format

The PR title should follow the format:

type(scope): concise message (max 50 chars)

Where:

• type is one of: feat, fix, docs, refactor, perf, test, chore.
• scope is optional and describes the part of the codebase affected (e.g., auth, ui, api).
• concise message is a short description of the change (max 50 chars).

📝 Change Type

Please select the type of change this PR introduces (choose one or more):

• feat: New feature.
• fix: Bug fix.
• docs: Documentation only changes.
• refactor: A code change that neither fixes a bug nor adds a feature.
• perf: Performance improvement.
• test: Adding missing tests or correcting existing tests.
• chore: Maintenance tasks (e.g., updating dependencies).

💡 Description

Briefly describe the change, its purpose, and the problem it solves.

Key Changes

🔗 Related Issues

List any issues this PR closes or relates to:

• Closes #IssueNumber (e.g., Closes #123)

✅ Checklist

Please ensure the following points are addressed before merging:

• I have performed a self-review of my own code.
• I have added/updated tests that prove my fix or feature works (if applicable).
• I have updated the documentation (if necessary).
• My code follows the project's style guidelines.