Decode HDF5 text that its writer declared ASCII

[cboulay]

Why

hdmf keys its string-decoding decision directly off the HDF5 character set. A writer that declares its strings H5T_CSET_ASCII rather than UTF-8 — aqnwb, and therefore every recording Orion produces — hands every string back as bytes where a pynwb-written file gives str. Filed upstream as NeurodataWithoutBorders/aqnwb#316, and being looked at.

That fix will not retire this one. Files already on disk keep the character set they were written with, so a reader has to survive both indefinitely.

Nothing raises. str(value) on bytes yields the repr — "b'cond_0'" — which looks like text, compares equal to nothing, and parses as no JSON.

What

Three read boundaries in NWBSlicer forwarded those bytes into places that only ever compare or parse them:

• Interval tables (slicer.py:239) were stringified with map(str, ...). A marker payload arrived as "b'{\"cause\": ...}'" — text json.loads rejects, so a consumer such as INTENT's cursor marker parser dropped every marker and reported nothing wrong.
• The electrodes label column (slicer.py:344) becomes the ch-axis coordinates that every downstream name-based channel selection matches against.
• Device.manufacturer (slicer.py:116) is parsed as a prefix when a caller names a stream by bare device (stream_keys=["NPLAY"] matching CereLink_NPLAY); a bytes value there would discard the stream in silence.

The third is a guard, not a live bug: hdmf happens to decode ASCII attributes on the way out even though it leaves datasets alone. I only found that out because the test asserting otherwise failed, so the comment and a test now pin the asymmetry rather than claim a fix.

A text series (markers, annotations) is decoded once at load rather than at each slice, so the three places that index dset — both slicer read paths and the iterator's — can't each forget to. Safe to materialize: text series are markers, short and few, on the order of the interval tables already read whole beside them.

as_text / as_text_array are exported from the package, since a downstream reader of these files needs the same primitive.

Test

The suite could not have caught this. Written by pynwb throughout, its text reads back as str and none of these paths is exercised — which is how the bug reached hardware.

The new ascii_nwb_path fixture restates the strings as fixed-length ASCII the way aqnwb writes them, carrying one of each kind of text a reader has to survive: spec-defined and custom electrodes columns, a custom interval-table column, a marker series, and the Device manufacturer attribute. It asserts first that they really do read back as bytes; without that guard the tests would pass against the very bug they exist to catch.

Reverting slicer.py alone fails exactly the four data-path tests.

Verification

• Full suite: 170 passed.
• ruff check / ruff format clean.