Empirically the DWG \"loaded\" bit doesn't track AutoCAD's XREF Manager
\"Loaded\"/\"Unloaded\" state reliably:
- File A: manager \"Loaded\", on-disk is_loaded = Some(true)
- File B: manager \"Loaded\", on-disk is_loaded = Some(false)
Same UI state, opposite bit values, so we were incorrectly skipping
xrefs the user wants loaded. Drop the `is_loaded == Some(false)` skip
and auto-resolve every xref again. The OOM problem this was meant to
mitigate is now addressed by the frustum culler, so loading more
xrefs no longer threatens the GPU budget.
The `BlockRecord::is_loaded` field + acadrust patch stay in place so
we can revisit once we identify the actual on-disk representation of
XREF→Unload (likely an XREF dependency record or
ACAD_XREF_PANEL_DATA xrecord).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
When the host DWG marks an xref as Unloaded (via XREF→Unload in
AutoCAD), the user explicitly chose NOT to load that reference. We
were ignoring that and pulling the external file in anyway, which
on large drawings could push GPU memory past the device budget.
Bump the acadrust dep to the branch that exposes
`BlockRecord::is_loaded`, then short-circuit `resolve_xrefs` for
any entry with `is_loaded == Some(false)`. New `XrefStatus::Unloaded`
surfaces this in the command-line log so the user can see which
references were skipped (and can re-load them via the XREF dialog).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
