Start v0.6.4 development and record the v0.6.3 release evidence - #47

v0.6.3 is public. This advances the source to 0.6.4.dev0 and records the
release evidence.

Published identity

PyPI and the GitHub Release expose identical files. The PyPI integrity API
exposes one Trusted Publisher attestation bundle per distribution, bound to
DaoyuanLi2816/mini-verl and release.yml.

A clean Windows Python 3.12 install from https://pypi.org/simple reported
miniverl 0.6.3, kept torch absent, and — given a reward scaffold whose top
level writes a marker file — refused to run it: the marker was never created
and the doctor reported top_level_call with code_executed: false.

One defect found during that verification

A scaffold saved with a UTF-8 byte-order mark is reported as syntax_error at
level not_present. CPython strips the BOM when it reads a source file; the
static checker decodes the bytes and hands the leading  to ast.parse,
which rejects it. A scaffold written by a Windows editor is therefore refused as
unparseable.

The direction is fail-closed — a legitimate file is rejected, nothing unsafe is
accepted — so it is not a security defect, but it is wrong. It is recorded as
the first v0.6.4 checklist item and fixed in a separate PR; v0.6.3 is
immutable and keeps the behaviour.

Changes here

• release-state.yaml: phase: development, stable 0.6.3 with its real
  release commit, development 0.6.4.dev0
• __version__, CITATION.cff and the docs version selector follow from it
• PROJECT_STATE.md canonical release line
• docs/generated/quality.json: status: released
• release checklist: an "After the v0.6.3 tag" record and a v0.6.4 section

python scripts/release_state.py --check passes. No frozen scientific artifact
is touched.