chore(components): rename Form/Input to Form/TextInput

[martinydeAI]

Links to issues

No issue — small follow-up to
PR #72's component
extraction, surfaced during review of that PR.

Description

Renames the existing <twig:Form:Input> component to
<twig:Form:TextInput>.

The component is text-shaped only — its styling
(rounded-lg border bg-surface px-3 py-2 text-base text-ink)
fits type="text", email, password, search. Pass
type="checkbox" and you'd get a giant white box rather than a
check. So the name "Form/Input" suggests a generic <input>
wrapper that handles any type, but the implementation is
narrower. Renaming to Form/TextInput matches the actual scope.

Paired with the new Form/Checkbox primitive landing on
PR #72, the Form/*
layer reads consistently:

Component	Wraps
Form/TextInput	text-shaped <input> (text, email, password, search)
Form/Checkbox	<input type=checkbox>
Form/Button	<button>
Form/Label	wrapping <label>

Only consumer today is templates/security/login.html.twig
(email and password fields); both are updated in the same commit.

Screenshot of the result

N/A — pure rename, no visual change.

Checklist

• My code is covered by test cases.
• My code passes our test (all our tests).
• My code passes our static analysis suite.
• My code passes our continuous integration process.

If your code does not pass all the requirements on the checklist you have to add a comment explaining why this change
should be exempt from the list.

Additional comments or questions

task test → 48 tests, 172 assertions pass (the login-flow
integration tests in SecurityControllerTest exercise the renamed
component end-to-end via the /login page).
task coding-standards-check → green.

This PR is independent of #72 — both can land in either order.
After both merge to develop, the Form/* primitive layer is
internally consistent with no name overloading the <input> or
<option> HTML semantics.

---

Details - AI specificities

Goal and motivation

• During review of PR #72
  the question came up of whether "Input" and "Option" were the
  right names for the new checkbox-row and facet components. The
  active conflict (Filter/Option overloading the HTML <option>
  element) was fixed in that PR by renaming to Filter/FacetItem
  before shipping. This PR closes the latent half: Form/Input is
  named generically but its styling is text-only.

Scope

• File rename: templates/components/Form/Input.html.twig →
  templates/components/Form/TextInput.html.twig. Captured via
  git mv so history follows.
• Two <twig:Form:Input> → <twig:Form:TextInput> usages in
  templates/security/login.html.twig.

Non-goals

• No styling changes. The renamed component's class set is
  unchanged.
• No prop changes. Signature stays
  id, name, type, value, autocomplete, required, autofocus.
• No new tests. The login functional test in
  SecurityControllerTest already covers the rendered form.
• No changes to controllers, services, or other templates.

Conventions applied

• Follows the Path/Pascal.html.twig naming convention used
  elsewhere in templates/components/.
• Pure rename — git mv preserves history; the new primitive
  layer (Form/TextInput, Form/Checkbox, future Form/Radio)
  doesn't overload any HTML element names.

Follow-up work intentionally out of scope

• Form/Radio primitive (will follow the same shape as
  Form/Checkbox when a radio-group facet variant lands).
• Any styling refinement on the renamed component.

Related

• PR #72 — introduces
  Form/Checkbox and the broader component extraction this PR
  closes the naming on.