docs: correct the dtype mapping reference for int/uint

[ehennestad]

Motivation

Problem — spec.getBasicDTypeMap maps the schema dtypes int and uint to int8 and uint8, and cites HDMF's hdmf.spec.spec as the reference for that mapping. Those two entries do not appear there: HDMF still treats int and uint as the 32-bit types. A developer checking the file against its own citation finds a contradiction and cannot tell which side is correct.

Solution — Cite the source the values actually come from. The 8-bit meaning was introduced by HDMF Schema Language 3.0, which HDMF has not adopted yet, so name that and note the discrepancy rather than leaving it to be rediscovered.

What changed

• The reference comment in spec.getBasicDTypeMap points at the HDMF Schema Language dtype table and the change that introduced the 8-bit meaning, and records that HDMF still uses the pre-3.0 meaning.

No mapping values change, so there is no behavioural difference and nothing to regenerate.

Background

• The 8-bit meaning comes from hdmf-schema-language#38, merged for the unreleased 3.0.0: "Changed the meaning of dtype: int from int32 to int8", with dtype: uint meaning uint8. Before 3.0, int was synonymous with int32 and uint was not listed.
• HDMF's DtypeHelper.primary_dtype_synonyms still maps int to int32 and uint to uint32, which is what the old citation pointed at.
• The divergence is tracked in hdmf-schema-language#50.

Examples

Comment-only change, so there is no before/after behaviour to show. The mapping is unchanged:

mapping = spec.getBasicDTypeMap();
fprintf('int  -> %s\nuint -> %s\n', mapping('int'), mapping('uint'));

int  -> int8
uint -> uint8

How to test

mapping = spec.getBasicDTypeMap();
assert(strcmp(mapping('int'), 'int8'))
assert(strcmp(mapping('uint'), 'uint8'))
help spec.getBasicDTypeMap

Checklist

• Have you ensured the PR description clearly describes the problem and solutions?
• Have you checked to ensure that there aren't other open or previously closed Pull Requests for the same change?
• If this PR fixes an issue, is the first line of the PR description fix #XX where XX is the issue number?

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.27%. Comparing base (2880afc) to head (b3e5958).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #878   +/-   ##
=======================================
  Coverage   95.27%   95.27%           
=======================================
  Files         234      234           
  Lines        8311     8311           
=======================================
  Hits         7918     7918           
  Misses        393      393           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.