DXF reader silently drops AcDbPolyline-subclass fields (LWPOLYLINE flags/closed, elevation) — no metadata entries for that subclass

[kretz]

Describe the bug

When reading a DXF file via DxfReader, LwPolyline entities parse their vertices correctly (codes 10/20/40/41/42/50/90/91, which are hardcoded in _readLwPolyline), but any field that falls through to the generic metadata-driven assignment path comes back as its default value instead of the file's actual data. This includes:

• flags / isClosed (group code 70)
• elevation (group code 38)

Confirmed root cause: there are zero references to AcDbPolyline anywhere under src/Metadata/LookupTables/ (I checked the built dist/Metadata/ output for v2.4.0). _readLwPolyline's default case falls back to:

return this.tryAssignCurrentValue(template.cadObject, map.subClasses.get(tmp.cadObject.subclassMarker));

Since map.subClasses.get("AcDbPolyline") has nothing to look up, codes 70/38 (and presumably other AcDbPolyline-only codes) are silently no-ops. There's no error or notification — the entity just comes back with isClosed: false and elevation: 0 regardless of the file's content.

To Reproduce

import { DxfReader } from "@node-projects/acad-ts";

const dxfText = [
  "0", "SECTION", "2", "HEADER", "0", "ENDSEC",
  "0", "SECTION", "2", "ENTITIES",
  "0", "LWPOLYLINE",
  "5", "1",
  "8", "outline",
  "100", "AcDbEntity",
  "100", "AcDbPolyline",
  "90", "3",
  "70", "1",   // closed flag set
  "38", "5",   // elevation
  "10", "0", "20", "0",
  "10", "10", "20", "0",
  "10", "10", "20", "10",
  "0", "ENDSEC", "0", "EOF",
].join("\n");

const doc = DxfReader.readFromStream(new TextEncoder().encode(dxfText));
const e = [...doc.modelSpace.entities][0];
console.log(e.isClosed, e.elevation); // logs: false 0

Expected behavior

e.isClosed should be true and e.elevation should be 5, matching the group codes in the input.

Environment

• @node-projects/acad-ts: 2.4.0
• Node 22 / Vitest, but this is pure parsing logic, unrelated to runtime

Additional context

• Verified this isn't a fixture-authoring mistake on my end: layer resolution (group code 8, a common Entity-level property) resolves correctly on both minimal fixtures and a real 82k-line AutoCAD-exported DXF sample, and heavy Polyline/vertex parsing is also fine — the gap is specifically scoped to AcDbPolyline-subclass fields on LwPolyline.
• I haven't checked whether the DWG binary reader (DwgObjectReader/DwgStreamReaders) shares this gap — that's a separate code path and untested by me for this specific field.
• Happy to send a PR adding the missing AcDbPolyline entries to the metadata lookup table if that's the right fix — wanted to confirm the intended approach first, since the metadata tables mention being "bootstrapped from the earlier generated metadata" rather than generated live from the upstream C# ACadSharp source.