Derive the confidentiality profile ID from the tag alone

[MichaelLeeHobbs]

The problem

Table E.1-1 gives the tag for its "Private Attributes" row as (gggg,eeee) where gggg is odd. The trailing prose is carried into both the tag and the slug derived from it, so the row is published as:

{
  "name": "Private Attributes",
  "tag": "(GGGG,EEEE) WHERE GGGG IS ODD",
  "stdCompIOD": "N",
  "basicProfile": "X",
  "rtnSafePrivOpt": "C",
  "id": "ggggeeee-where-gggg-is-odd"
}

Out of 621 rows in confidentiality_profile_attributes.json this is the only one whose id is not an eight-character tag slug, and the only one whose tag is a sentence. The .upper() that normalises hex digits also shouts the prose.

Repeating-group rows in the same table are already handled correctly — (50xx,xxxx) → 50xxxxxx, (60xx,3000) → 60xx3000 — so this row is the sole exception to a shape consumers can otherwise rely on.

The change

Isolate the tag before deriving the ID. The row is then published as:

{ "tag": "(GGGG,EEEE)", "id": "ggggeeee" }

which matches the existing repeating-group rows. Cells containing no tag at all are passed through unchanged, so this cannot silently blank a future row.

The qualifier is not lost in any meaningful sense: an odd group number is precisely what makes an attribute private (PS3.5 Section 7.8.1), which the row's own name already states.

Note on compatibility

This changes one id and one tag value. I judged that acceptable under the repository's stated guarantee that "bugs or incorrect data will be fixed", and because a consumer keying on ggggeeee-where-gggg-is-odd is relying on the defect. Happy to drop this if you would rather keep the value frozen — the alternative would be to fix only the uppercasing and leave the ID as it is.

Verification

• pytest tests/extract_conf_profile_attributes_test.py — 5 new tests covering a normal tag, a repeating-group tag, the Private Attributes row, a cell with no tag, and the resulting IDs.
• pytest tests/ --ignore=tests/end_to_end_test.py — 44 passed, 2 skipped.
• flake8 and mypy clean on both changed files.

Six errors in standard_workarounds_test.py also occur on an unmodified checkout: parse_html_file opens the standard HTML without specifying an encoding, so it fails under a cp1252 default locale. Unrelated to this change, but it does mean the unit suite cannot be run on Windows as-is — happy to send a one-line encoding='utf-8' fix separately if that is useful.

Found while triaging the issue backlog (#131). Independent of #130.