Task: Choose the root legal entity from the register

The Operational card asks for the tenant's root legal entity the way the GLEIF entity card already does: by name or LEI, from the entities the deployment holds. A person with no entity yet leaves it out, which is the case the card supports today and keeps.

• The Operational card's root entity is chosen from a search over the deployment's legal entities, not typed, and the card still allows the entity to be left out.
• A value that is not an LEI's shape is refused with a sentence about the field, so a mistyped code cannot reach the publication. A twenty-character code the register does not hold is still the publication's to refuse; the browser cannot produce one, because its field is a search.
• The card's own words and the journey documents say the same thing.
• A browser walk on the live deployment shows the search, the matches the deployment holds, and the chosen entity carried into the review.

The card's difference from the GLEIF entity card is one column: the seeded row declares data_type: string, so the form renders a text box, while legal_entity renders the search. So the change is the row, not the form:

1. The seeded row: empty_operational's root_lei becomes legal_entity, and its label and hint are brought in line with what the field now does.
2. The form needs no change: parts.tsx already renders legal_entity as LegalEntitySearch, and that component shows its search box while the value is empty, so the optional case is the empty state rather than a new branch.
3. The server already checks the shape: a legal_entity value must be twenty alphanumeric characters, so a code that is not an LEI is refused naming the field instead of reaching the publication.
4. The live database predates the seed, so the row is set there by hand for the walk, and the walk is what proves the card. A fresh installation reads the seeded row.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The Operational card now asks the deployment for its root legal entity the way the GLEIF entity card does, and the change was one seeded row: legal_entity instead of string. The form was already able to render that type as the search, and the server already checked its shape, so no screen and no handler changed.

The card was walked in a browser on the live deployment. It shows a search box naming the field; the search answers with the entities the deployment holds, two of them for barclays; the chosen entity stands in the field with its LEI, its country and the parties its hierarchy would create; and the review carries the LEI. The walk is evidence/operational_root_legal_entity.txt, with four screenshots.

The gap the story recorded is closed for the browser: its field is a search, so nobody can type a code the deployment cannot check. The value that used to reach the publication and come back as its SQL is the one the parameter check now refuses first, and its new test states that with the eighteen-character code an earlier walk mistyped. What the check guards is the LEI's shape and not its existence, so a twenty-character code the register does not hold is still the publication's to refuse; that path is the shell's. The card stays optional, and a second test proves the check accepts the entity left out, which is the tenant whose parties come from the party stage.