Fix issue #400

[lohedges]

The AMBER prmtop writer incorrectly applied a / 3 scaling to the per-molecule atom offset when computing global CMAP atom indices. This scaling is correct for bonds, angles and dihedrals (which store indices as 3 × atom_index per the AMBER coordinate-array convention), but CMAP terms use plain 1-based atom numbers and require no such scaling. For the first molecule in the system the offset is zero so the error was silent, which is why the existing single-chain test never caught it. For any subsequent molecule the offset was divided by three, producing atom numbers that landed in the wrong molecule. When the writer then re-parsed its own output to validate it, the consistency check raised "there is a cmap between more than one different molecule". A secondary off-by-one in the reader's indexCMAPs function (1-based atom numbers were used directly to index a 0-based array) was corrected at the same time. The bug was exposed by a GLYCAM glycoprotein topology with three large protein/glycan chains, each carrying backbone CMAP terms. A regression test (test_amber_multichain_cmap) has been added that loads this multi-chain topology, writes it back to prmtop format, and verifies that each chain's CMAP term count is preserved across the roundtrip.

This PR closes #400. (Debugged with help from Claude code.)

• I confirm that I have merged the latest version of devel into this branch before issuing this pull request (e.g. by running git pull origin devel): [y]
• I confirm that I have added a changelog entry to the changelog (we will add a link to this PR as part of the review): [y]
• I confirm that I have permission to release this code under the GPL3 license: [y]

[chryswoods]

Good fix :-)