docs: drop code references to local plan files

src/Model/ApplicationFormSubmissionDto.php

@@ -8,8 +8,8 @@ use Symfony\Component\Validator\Context\ExecutionContextInterface;
 /**
  * One submitted TYPO3 form, mapped from the request body by #[MapRequestPayload].
  *
- * Two rules from the contract (.ddev/plans/MYEP-APPLICATION-ENDPOINT.md §3.2, §3.3) shape this
- * class and must survive any rewrite:
+ * Two rules from the contract with the TYPO3 side shape this class and must survive any
+ * rewrite:
  *
  * - **Unknown keys are ignored, never rejected.** The mapped vocabulary grows on the TYPO3
  *   side without a release here, so nothing may switch the serializer's ALLOW_EXTRA_ATTRIBUTES
@@ -21,8 +21,7 @@ use Symfony\Component\Validator\Context\ExecutionContextInterface;
  *   Vorname, Geschlecht, EMail, PLZ, Straße) - a payload without those cannot become a teamer at
  *   all, and asking a reviewer to retype them from the answers would be worse than refusing the
  *   payload. The endpoint only ever receives application forms, so this holds for every payload and
- *   there is no form-type discriminator
- *   (.ddev/plans/application-form-teamer-provisioning.md).
+ *   there is no form-type discriminator.
  *
  *   Everything beyond the nine - phone, mobile, nationality, bank details - stays optional and is
  *   filled in by the teamer themselves afterwards, so an absent key there still means "not part of
@@ -334,7 +333,7 @@ class ApplicationFormSubmissionDto
     /**
      * The blob as it is stored: numbers arrive as strings from the form editor but nothing stops
      * a mapping from sending one unquoted, and an empty answer is dropped rather than kept -
-     * TYPO3 strips those before sending (§3.3), so a label present in the blob always has
+     * TYPO3 strips those before sending, so a label present in the blob always has
      * content. The received order is the form's order and is never touched.
      *
      * @return array<string, string|bool|list<string>>