Document the slicer/setting DELETE route and clarify a few field semantics

[pascalprey]

While cleaning up a Bambu Cloud account that had hit the user-preset limit, I ended up
verifying a couple of things that were either missing from cloud-http.md or slightly
off. All of it was checked against a live account in August 2026 with Bambu Studio
02.07.01.62.

New: DELETE /v1/iot-service/api/slicer/setting/{SETTING_ID}

Deletes a user preset server-side. Returns the usual {"message": "success"}; afterwards
a GET on the same id returns HTTP 400 and the entry is gone from the private array.
I ran 596 of these in one pass with no failures. This is the route behind
bambu_network_delete_setting, which bambu_networking.dll exports alongside
get_setting_list, get_setting_list2, put_setting and request_setting_id.

New: notes on the private preset quota

Bambu Studio complains that the cloud preset limit is exceeded, but offers no way to see
or remove the offending entries when they no longer sync down. Two details that cost me
time and might save someone else's:

• The quota differs per category. print.private had stopped at exactly 100 while
  filament.private held 499, so I have deliberately not claimed a single number.
• The local .info files are not a mirror of the cloud. An empty user_id does not mean
  the preset is absent server-side, so deleting local files frees no quota.

Clarified: GET /v1/user-service/my/tasks

• costTime is the slice estimate, not the actual runtime. Aborted jobs still carry the
  full estimate while endTime - startTime is short, so summing costTime overstates
  print hours. I got 206 h that way versus 107 h actual.
• status 2 = finished, 3 = aborted/failed; failedType was 0 in both cases.
• material exists but was empty on all 57 tasks; the real filament data sits in
  amsDetailMapping, whose shape I have documented.
• Added the full field list observed on current responses (~48 fields versus the 15 in the
  existing example).

Clarified: GET /v1/iot-service/api/user/bind

Current responses also return print_job, nozzle_diameter and dev_structure
(I3 vs CoreXY). On newer models dev_model_name returns the marketing name (P2S)
rather than an internal code like BL-P001.

Happy to adjust the wording or split this up if you would rather have it in separate
commits.