Add support for migration of statuses in direct transfer
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=566237)
</details>
<!--IssueSummary end-->
Currently Issue statuses, or custom statuses, aren't imported during direct transfer. Without these, project board lists based on statuses cannot be imported either.
Statuses are found through the `Issue#current_status` method:
```
pry(main)> issue.current_status
WorkItems::Statuses::CurrentStatus Load (0.8ms) SELECT "work_item_current_statuses".* FROM "work_item_current_statuses" WHERE "work_item_current_statuses"."work_item_id" = 1747 LIMIT 1 /*application:console,db_config_database:gitlabhq_development,db_config_name:main,console_hostname:cdrago--20250425-7XQVQ,console_username:carladrago,line:(pry):57:in `__pry__'*/
=> #<WorkItems::Statuses::CurrentStatus:0x000000033675c3d8
id: 18,
namespace_id: 407,
work_item_id: 1747,
system_defined_status_id: 2,
custom_status_id: nil,
updated_at: Thu, 28 Aug 2025 15:35:50.692281000 UTC +00:00>
```
The [Gitlab::ImportExport::Base::ObjectBuilder](https://gitlab.com/gitlab-org/gitlab/-/blob/09973c7e6b9061a758e69ad94c60b5c59090c568/lib/gitlab/import_export/base/object_builder.rb#L17) then needs to be updated to connect/create the status records.
From discussion on a related [MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/202374#note_2713683448):
> For context, when the import process needs to associate records with existing records, it finds the existing records using [Gitlab::ImportExport::Base::ObjectBuilder](https://gitlab.com/gitlab-org/gitlab/-/blob/09973c7e6b9061a758e69ad94c60b5c59090c568/lib/gitlab/import_export/base/object_builder.rb#L17), which relies on unique attributes to locate the corresponding record. For example, to find an existing `label`, the title is used.
>
> On Project, I think the `status` list isn't imported because the `system_defined_status_identifier` field is marked as ignored. Because of that, the `ProjectLabel` is built without the required field, making the list invalid.
>
> Take the tree below:
>
> ```
> tree:
> project:
> boards:
> - lists:
> - label:
> ```
>
> And the following NDJSON file:
>
> ```
> {
> "name": "Board"
> "lists": [
> {
> "list_type": "label",
> "label": {
> "title": "Label 1",
> "type": "ProjectLabel"
> }
> },
> {
> "list_type": "status",
> "system_defined_status_identifier: 2
> }
> ]
> }
> ```
>
> During the import process, a Board object is created along with the nested lists. Since `label` is marked as [EXISTING_OBJECT_RELATIONS](https://gitlab.com/gitlab-org/gitlab/-/blob/172fa7c2fbf29631c45a0a6e7cfe62857ebaee9b/lib/gitlab/import_export/group/relation_factory.rb#L17-28), the object builder attempts to find an existing label with the title "Label 1" and associates it with the list.
>
> As mentioned above, the `system_defined_status_identifier` is ignored. So, the second list is created without the field.
>
> So, at the end, the following object is built:
>
> ```
> Board.new(
> name: "Board",
> lists: [
> ProjectLabel.new(list_type: "label", label_id: <ID of the existing "Label 1" found via Object builder>,
> ProjectLabel.new(list_type: "status"]
> ]
> )
> ```
>
> Then, when the board record is saved by [Gitlab::ImportExport::Base::RelationObjectSaver](https://gitlab.com/gitlab-org/gitlab/-/blob/d5ec052fc70f73d9119e9409f36828c2f7294932/lib/gitlab/import_export/base/relation_object_saver.rb#L92), the status list should be ignored, as it is invalid.
>
> By the way, List status also supports Custom Status, which is a different association that appears to be stored in the top-level group.
issue