• docs/v322_new.md exec/inventory_archives.js exec/load/filecontents_lib

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Mon Sep 21 22:21:21 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/d9669612528f11e627aa00e9
    Modified Files:
    docs/v322_new.md exec/inventory_archives.js exec/load/filecontents_lib.js exec/tests/filecontents_test.js
    Log Message:
    filecontents: keep the listing in the file record's own auxdata

    A per-area data/dirs/<code>.contents file meant that serving one listing
    parsed a single JSON object holding every listing in the area. Measured
    on the largest area here, one view read 4.78 MB and spent 31 ms and
    34.8 MB of RSS to return 1 record out of 76, and a cold view
    re-serialized the whole file to add one. That heap is the same
    mozjs185 pressure the stored listings exist to avoid.

    In auxdata the cost is the record's own data blocks: the same 295 KB
    listing reads in 2 ms and 1.6 MB, a typical record in no measurable time
    or heap, and neither depends on how many archives the area holds. The
    listing is also removed with the file record, so nothing is left behind
    when a file goes away, and there is no second file, lock or orphan sweep
    to maintain.

    The listing goes under an "archive_contents" key rather than owning the
    slot, and auxdata that this library did not write, or cannot parse, is
    left alone instead of replaced. put() hands the description and
    extended description back with every write, so a record survives a build
    whose FileBase.update() drops the text it was not given or refuses an
    object carrying only auxdata.

    inventory_archives.js loses its batched merge and its lock: each record
    is now written on its own.

    The record carries the format version the store file's wrapper used to
    hold, in place of a type field that named what the key already says and
    that nothing read. A record written in an encoding this code does not
    know now reads as absent and is extracted again, rather than being
    parsed on the assumption that it matches.

    No migration is needed: a missing record is extracted and stored on
    first view, so the base warms itself. The data/dirs/*.contents files
    from the previous arrangement are simply unused.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)