Editors cannot correct the data and software availability statement

## The problem

`dataAvailabilityStatement` can only be written in two places today, and neither
is an editorial form:

1. **The submission wizard, by the author** — the CODECHECK section of the wizard,
persisted by `CodecheckPlugin::saveWizardFieldsFromRequest()` on the
`Submission::validate` hook.
2. **The REST API** — `PUT /submissions/{id}/publications/{id}`, which works because
the plugin puts the field on the publication schema with `apiSummary: true`.

Everywhere else is read-only: the CODECHECK metadata form's paper-metadata panel,
the wizard's review step, and the article landing page.

So once a submission has been made, **nobody in the editorial workflow can add or
correct the statement.** That matters now that it is rendered on every article
landing page: an author who left it empty, wrote it in the wrong field, or needs a
correction after acceptance has no route to fix it, and neither does an editor. A
journal that wants the statement filled in for every article has no way to make
that happen.

## What to do

Add the field to OJS's own publication **Metadata** form, alongside the other
publication metadata an editor can edit, using the `Form::config::before` hook the
plugin already uses for the submission opt-in checkbox.

```php
Hook::add('Form::config::before', function (string $hookName, FormComponent $form): bool {
if ($form->id !== PKPMetadataForm::FORM_METADATA) {
return false;
}

$form->addField(new FieldTextarea('dataAvailabilityStatement', [
'label' => __('plugins.generic.codecheck.dataSoftwareAvailability'),
'description' => __('plugins.generic.codecheck.dataSoftwareAvailability.description'),
'value' => $form->publication->getData('dataAvailabilityStatement'),
]));

return false;
});
```

Established while researching this, against OJS 3.5.0-5:

- `FormComponent::getConfig()` fires the hook, and that config is what
`PKPSubmissionController::getPublicationMetadataForm()` serves to the Metadata tab.
- The form id is `'metadata'` (`PKPMetadataForm::FORM_METADATA`), and the publication
is on the form object as `public Publication $publication`, so the current value
comes from there rather than from the request.
- **No `groupId` is needed.** `PKPMetadataForm` defines no groups, and `getConfig()`
adds the `default` group *after* the hook and remaps every field onto it.
- **No save code is needed.** The form is a `PUT` against the publication API and the
field is already on the publication schema, so it round-trips on its own. This is
the opposite of the wizard, which needs `saveWizardFieldsFromRequest()` precisely
because it posts outside that API.

## Two traps

- **Match the form id exactly, never `instanceof`.** `ForTheEditors` extends
`PKPMetadataForm` and is the wizard's "For the Editors" step, so an `instanceof`
check would add the field there too — shown twice in the wizard, beside the
plugin's own field.
- **`FieldTextarea`, not `FieldRichTextarea`.** The article page renders the statement
through `strip_unsafe_html|nl2br` and the wizard uses a plain textarea, so a
rich-text field would admit markup the front end then strips.

## Not yet verified

Whether the Metadata tab is hidden when a journal disables every built-in metadata
field. `PKPMetadataForm::enabled()` only gates OJS's *own* fields off context
settings, not fields a plugin adds, so the CODECHECK field should appear regardless
— but this needs clicking through such a journal before it is relied on.

## Related

The field is `multilingual: false`, so whatever is added here inherits the
single-language limitation filed as #164.

Start at the existing Form::config::before hook that adds the submission opt-in checkbox, then inspect PKPMetadataForm::FORM_METADATA and PKPSubmissionController::getPublicationMetadataForm(). Add the field only for the exact metadata form ID and verify that the publication API saves and reloads it without duplicating it in the editor wizard.

Written by the indexing model from the issue text.