FIX: Register created converters and targets only after the response is built

[varunj-msft]

Description

Split out of #2959. ConverterService.create_converter_async and TargetService.create_target_async registered the new object first and mapped it to the API response afterwards. If mapping failed (identifier generation, capabilities, nested targets, DTO validation), the request failed but the object stayed registered, and the converter's uploaded files were left behind. For example, TextTarget with custom_configuration={} returned 500 and stayed registered, so retrying with the same name failed with "already exists".

Create is now atomic:

• Order: both services construct the object with the registry (create_instance), build the response, and register it last. The mappers read only the object and class metadata, never the instance registry.
• Name check: as before, the converter flow checks the name again after its uploads (an await), so a request that lost the name to a concurrent create never runs its constructor. Nothing between that check and register awaits.
• Cleanup: any failure, including registration, removes the request's uploaded files, and nothing is registered.

Coordination:

• FIX: Accept only supported external inputs when building components #2959 adds Registry.create_instance_from_external_input, which REST creation must use, and changes these same create calls. Whichever merges second keeps this PR's construct → map → register order and builds with create_instance_from_external_input. Git merges this PR's create_instance(...) line into the converter service outside the conflict markers, so check that line; FIX: Accept only supported external inputs when building components #2959's service tests fail if the external check is lost.
• FIX: Keep backend media and upload inputs inside managed storage #2958 (same story) edits the same create_target_async docstring in target_service.py; whichever merges second keeps both descriptions.

Tests and Documentation

• Converter tests (tests/unit/backend/test_converter_service.py):
  • a mapping failure leaves nothing registered and no uploads;
  • a name taken during the upload stops construction;
  • a registration failure removes the upload.
• Target tests (tests/unit/backend/test_target_service.py): a mapping failure leaves nothing registered.
• Both mapping-failure tests fail on main.
• python -m pytest tests/unit/backend -n 4 — 1713 passed, 4 skipped.
• ruff format / ruff check — passed; ty check pyrit/ — no new diagnostics; pre-commit hooks pass.
• build_and_test workflow run on the fork at c298f5c: pre-commit on ubuntu/windows/macOS and make unit-test-junit on ubuntu/windows/macOS x Python 3.11-3.14 x dev/dev_all — all 35 jobs passed.
• Live backend: TextTarget with custom_configuration={} still returns 500 on this branch (FIX: Accept only supported external inputs when building components #2959 makes it a 400), but the target is not registered and the same name can be created right after.
• No docs changed.