Runner deprecations: registration_deprecates_at is declared on the response but never returned

actions/get-runner-version-deprecation-for-repo と actions/get-runner-version-deprecation-for-org の OpenAPI 200-response スキーマを特定します。registration_deprecates_at のスキーマと説明を、観測されたレスポンスおよび兄弟フィールドである runtime_deprecates_at と比較します。仕様がフィールドの未設定状態を文書化するか、値が設定されたレスポンスを正確に反映すれば完了です。

Description

The runner version end-of-life operations actions/get-runner-version-deprecation-for-repo
and actions/get-runner-version-deprecation-for-org declare registration_deprecates_at
on their 200 schema, a nullable date-time, "The date after which this runner version
can no longer register".

I have not been able to get it returned. Every version between 2.321.0 and 2.337.0
comes back with runner_version and runtime_deprecates_at only:

2.325.0   {"runner_version":"2.325.0","runtime_deprecates_at":"2025-09-11T13:58:34Z"}
2.328.0   {"runner_version":"2.328.0","runtime_deprecates_at":"2025-12-16T17:40:26Z"}
2.335.1   {"runner_version":"2.335.1","runtime_deprecates_at":"2026-09-24T15:30:55Z"}
2.337.0   {"runner_version":"2.337.0","runtime_deprecates_at":null}

2.325.0 and 2.328.0 are below the 2.329.0 floor that
the enforcement timeline
says "won't be able to register or reregister", so if any version has a registration
date it should be those. It is not an omit-when-null rule either, since 2.337.0
keeps the sibling key as an explicit null.

Only runner_version is required, so omitting it is legal against the description.
That is what makes it a client problem rather than a validation error: codegen yields
an optional nullable field that reads the same whether nothing populates it or this
version genuinely has no registration deadline, and those want opposite handling.

Expected

Either registration_deprecates_at is populated, or its description says it is not
currently populated, so clients know the absence is not a signal.