Docs: Settle how Alignment and Arrangement constants are spelled #5

What

docs/SPEC.md §7 records the spelling of layout constants as not settled: alignment.py and arrangement.py tell callers to write Alignment.Center() / Arrangement.End(), and tests/test_alignment_modules.py enforces that text, while layout/__init__.py and UI.ipynb read them without parentheses.

Why

The binder settled it. PythonMultiplatform 46be0212 evaluates a bound static getter on attribute access, so Alignment.Center is the value and Alignment.Center() raises TypeError. The notebook writes the same attribute form. The documentation prescribing the call form is now wrong.

The examples also imported pythonx.compose.*, which the binder no longer provides; until this package re-exports them (SPEC §3), the importable name is the Kotlin one.

Done when

• alignment.py and arrangement.py show the attribute form with androidx.compose.* imports and say the call form raises TypeError.
• tests/test_alignment_modules.py checks that, and fails against the old sources (red observed).
• SPEC §7 and "Outside intent" §6, PROJECT.md and docs/guide/status.html stop calling the spelling undecided. What stays open is the notebook's grouped form (Alignment.Horizontal.End), which is a §3 re-export question.
• python3 tools/check_guide.py reports 0 findings.
• The suite goes from 39 passed / 37 skipped (no PythonMultiplatform checkout) and 39 passed / 37 failed (with one) to 40 / 37 in each. The 37 are the existing register_package failures.