test: Promote the center and isdigit function-library fixtures

[leongdl]

Promotes the two remaining function-library fixtures out of EXPR/jobs/proposed/ and into jobs/, where the runner discovers them. Both spec decisions they were waiting on have landed, and both fixtures pass.

expr2.2.4--center-odd-padding

Section 2.2.4 does not say which side of an odd pad takes the extra space. Per @mwiebe's review: #177 settles ambiguities of this kind by matching Python. CPython's 'hi'.center(7) is ' hi ' (extra space left), which is what the fixture already asserted as a strawman and is now the rule.

expr2.2.4--isdigit-unicode

The classification functions carry Python str semantics, and openjd-rs#341 implemented that from CPython-generated tables. Per @mwiebe's review, the Unicode expectation now holds, so the fixture goes live asserting isdigit is true for U+0663 and U+0969.

Coverage note: #177 adds expr2.2.4--string-classification-unicode, which is a superset for U+0663 (same ISDIGIT_ARABIC marker). This fixture also covers U+0969, so it is not a pure duplicate, but it is reasonable to fold it into #177's fixture instead if you would rather have one file. Say the word and I will drop it.

Fixture changes made while promoting

• Rewrote both headers: dropped the PARKED framing and the 2026-08 divergence tables, and stated the spec rule, the inputs, and what a wrong implementation prints.
• Wrote the digits as \u0663 and \u0969 escapes so the file stays ASCII. The runner reads fixtures with open(path) at the locale encoding, which mojibakes a UTF-8 literal on Windows. Same reason fix: Specify Python str semantics for character classification functions #177 uses escapes.
• Bracketed the isdigit assertions, matching the sibling expr2.2.4--string-classification fixture. The runner matches output as a substring, so an unbracketed value is a weaker assertion.
• Deleted proposed/README-func-lib.md. Nothing is left parked in it: the repr_py fixture was promoted on test: repr_py control-character conformance tests #162.

The third fixture from the original description, expr2.2.6--repr-py-newline-roundtrip, was already promoted on #162 and dropped from this branch.

[leongdl]

Quorum verdict: GOOD-WITH-NITS — spec: EL §2.2.4 leaves 'digit' undefined while §2.2.5 gives \d explicit Unicode semantics — correctly classified as a spec ambiguity, and the README's dual-run (both implementations ASCII-only, agreeing) matches the sweep. Nits: (1) the fixture header claims 'live implementation divergence' — there is none; both agree, the divergence is vs host-language str.isdigit — align the header with the README; (2) the strawman asserts Unicode-true, the OPPOSITE of the de facto agreement — if the spec ratifies ASCII (likely), the expectation flips; two reviewers suggest either flipping now or leaving this out of the inventory entirely since it prejudges an open spec decision rather than pinning a bug.

[leongdl]

Quorum review (5 independent agents). 3 fixtures + README. Net: 1 GOOD, 1 GOOD-WITH-NITS, 1 NOT-GOOD requiring a README rewrite before merge. The center-odd-padding README is internally contradictory and factually wrong about CPython (verified by execution: 'hi'.center(7) == ' hi ', extra space LEFT); per the 2026-08-12 sweep, openjd-rs now matches CPython and the PYTHON CLI is the outlier — the fixture's committed expectation actually matches the de facto answer, and the README is the defect. Cross-PR blocker: this branch and PR #164 both create EXPR/proposed/README.md (verified add/add conflict).

[leongdl]

Quorum-review fixes applied and pushed (rebased onto mainline 3069673):

• expr2.2.4--center-odd-padding README/header rewritten on the measured facts (the NOT-GOOD): CPython's 'hi'.center(7) is ' hi ' — extra space LEFT (verified by execution, three independent runs this review); current openjd-rs matches CPython (re-verified against an upstream/main build: emits ' hi '); the Python openjd CLI is now the right-heavy outlier. The fixture's committed expectation was correct all along — the old README's "both implementations are right-heavy / the expectation was wrong" claims are retracted in the new text.
• expr2.2.4--isdigit-unicode: header reframed as spec ambiguity with no divergence between the openjd implementations (both ASCII-only; the divergence is vs host CPython), and the strawman's flip-on-ASCII-ratification path is documented.
• expr2.2.6--repr-py-newline-roundtrip: stale "bug in openjd-rs" comment corrected to BOTH implementations.
• Restructured to kind-level parking (EXPR/jobs/proposed/) with a family-named README (README-func-lib.md) — removes the add/add merge conflict with test: [expected failures] EXPR fixtures needing implementation fixes #164.

[leongdl]

CI on fb2898c: both promoted fixtures are now discovered by the runner and pass on every lane that has completed.

Lane	OS	Result	Suite total
Conformance Tests (Rust)	ubuntu	✓ expr2.2.4--center-odd-padding, ✓ expr2.2.4--isdigit-unicode	1184 passed, 0 failed
Conformance Tests (Rust)	windows	both ✓	1139 passed, 0 failed
Conformance Tests (Python)	ubuntu	both ✓	1184 passed, 0 failed
Conformance Tests (Python)	windows	both ✓	1139 passed, 0 failed

macOS (Rust lane) has been queued for 45 minutes without starting, which is a hosted-runner backlog rather than a result. Both fixtures are platform-independent string operations and pass on the other four lanes.

Worth recording because it retracts an earlier measurement: the old center-odd-padding header claimed the Python openjd CLI was the right-heavy outlier and would fail this fixture. It passes. Whatever the 2026-08 sweep measured, the current Python CLI agrees with CPython and openjd-rs on 'hi'.center(7) == ' hi ', so there is no live divergence left on either fixture.