When sync-cli fails on a notebook resource with a bare
aiohttp.ServerTimeoutError() or asyncio.TimeoutError() (both have
empty __str__), the failure log emitted by resources_handler reads
exactly:

  ERROR - [notebooks - <id>] -

The trailing dash + space + newline is literal — the error body is the
empty string, not truncated. Operators are left with no signal
distinguishing a timeout from a 5xx with empty body from a network
reset.

Introduce format_exc_for_log(exc) in utils/resource_utils.py:
- timeout family (asyncio.TimeoutError, aiohttp.ServerTimeoutError)
  -> 'timeout: <ClassName>[: <msg>]' so 'timeout:' is greppable.
- non-empty str(exc) -> verbatim (no regression for the common path;
  CustomClientHTTPError / SkipResource / etc. unchanged).
- empty str(exc) -> falls back to the exception class name.

Applied at all four failure-log sites in resources_handler.py:
_apply_resource_cb (the failure site this issue surfaced from),
_import_resource, _force_missing_dep_import_cb, _cleanup_worker. The
import path additionally promotes the exception detail from DEBUG
into the ERROR line — operator log harvests only see ERROR, so the
previous DEBUG-only attachment was invisible at default verbosity.

This makes the error visible; it does not change the underlying
timeout. Tuning that is a follow-up once the type is visible.

…resource (#582)

In dynamic infrastructure (autoscaled VMs, ephemeral GKE nodes,
short-lived containers), it's common for hosts to exist in the source
org's tag inventory but no longer exist on the destination by the time
sync runs. The destination API correctly returns
`404 Not Found - {"errors":["Host doesn't exist"]}` for these.

Before this change, every such 404 raised CustomClientHTTPError, which
resources_handler's generic `except Exception` bucketed as a hard
failure, producing an ERROR line per missing host and aborting the
whole host_tags resource for that run.

After: 404 -> log INFO + raise SkipResource so the existing handler
SkipResource branch buckets it as `skipped`. Other status codes
(4xx/5xx) continue to propagate so the retry layer and failure
accounting still engage.

- Caught in update_resource; create_resource delegates so the same
  skip fires there.
- Logged at INFO via the project's LOGGER_NAME logger so a future
  refactor cannot accidentally promote the line back to ERROR.
- 9 new unit tests pin the contract: 404 skips, 400/403/500 propagate
  (with explicit status_code assertions), happy-path unchanged,
  create-vs-update delegation, multi-host loop continues, all-404
  path completes cleanly.

Co-authored-by: dd-octo-sts[bot] <200755185+dd-octo-sts[bot]@users.noreply.github.com>