Signal unreadable document dimensions in document/info and open_document

[loonghao]

Problem

Document.width / Document.height are read through to_float(), which collapses any
unconvertible value into its default (0.0) and only leaves a logger.warning. A client
therefore cannot distinguish a document that is genuinely zero-sized from one whose
dimensions Photoshop never reported — the symptom reported in issue #55 stayed invisible
rather than fixed.

Change

• Added try_float() next to to_float(). It applies the same conversion rules but returns
  an UNCONVERTIBLE sentinel instead of a stand-in number, so callers can tell a real 0.0
  apart from an unreadable measurement. The warning log is kept.
• photoshop://document/info and the photoshop_open_document tool now use try_float().
  When either dimension is unreadable, the payload gains dimensions_unavailable: true
  while width/height remain numeric (0.0).
• to_float() and the create_document call site are unchanged.

Payload contract

This is an additive, non-breaking change. The new field is only present when dimensions
cannot be read, so consumers that ignore unknown keys see the exact same payload shape as
before. Existing fields (name, width, height, resolution, layers_count,
success, document_name) are never removed or renamed.

// dimensions unreadable
{"name": "a.psd", "width": 0.0, "height": 0.0, "resolution": 72, "layers_count": 0, "dimensions_unavailable": true}

// dimensions readable — field absent
{"name": "a.psd", "width": 1920.0, "height": 1080.0, "resolution": 72, "layers_count": 0}

Tests

Extended tests/unit/test_dimension_utils.py, reusing the existing host-free fakes:
try_float behaviour (including that a genuine 0 is not the sentinel); both branches for
the photoshop://document/info resource and the photoshop_open_document tool; readable
values as plain float and as UnitValue; unreadable values as opaque objects, None, and a
UnitValue with a non-numeric .value; and a genuine zero that must stay unflagged.

Verified with pytest tests/unit -q.

Note

tests/unit/test_stdio_log_pollution.py::test_stdio_session_stdout_is_pure_jsonrpc is
intermittently flaky on this machine independent of this change — it fails roughly 1 run in
8 on an unmodified main checkout, since it asserts on the output of a subprocess session.
Reproduced before touching any code; not addressed here.