Flag the input-checkbox and input-submit SDCs noUi so Canvas does not offer theme-internal atoms as components

Problem/Motivation

Every other theme-internal Single Directory Component in this theme carries noUi: true, which is how Canvas is told the component is a render-layer building block and not something a site builder should be able to place on a page. Drupal\canvas\Plugin\Canvas\ComponentSource\SingleDirectoryComponentDiscovery::discover() filters those out, so Canvas never creates a Component config entity for them.

Two atoms are missing the flag:

• components/atoms/input-checkbox/input-checkbox.component.yml
• components/atoms/input-submit/input-submit.component.yml

Both are pure Bootstrap form-input wrappers: their whole prop set is *_utility_classes, children and attributes (a Drupal\Core\Template\Attribute). There is nothing for a content author to compose with, and they sit beside details, fieldset, form-element, radios, select and the rest of the form atoms, which all do carry noUi: true.

Because they are not flagged, Canvas creates them as enabled Component config entities on the next cache rebuild after the theme is installed, and they show up in the Canvas component library. The Horizon Aid recipe has been papering over this by shipping a Component config entity for each of them and then disabling it again with a disable: [] config action - see the related issue on Horizon Aid, where those shipped entities are the source of 477 PHP warnings on every install.

Steps to reproduce

ddev drush php:eval '
$disc = \Drupal::classResolver("Drupal\\canvas\\Plugin\\Canvas\\ComponentSource\\SingleDirectoryComponentDiscovery");
foreach (["input-checkbox", "input-submit", "details"] as $c) {
  $id = "vartheme_bs5_horizonaid:$c";
  try { $disc->checkRequirements($id); echo "$c: Canvas will create a Component for this\n"; }
  catch (\Throwable $e) { echo "$c: ignored by Canvas\n"; }
}'

Result on 1.0.0:

input-checkbox: Canvas will create a Component for this
input-submit: Canvas will create a Component for this
details: ignored by Canvas

Proposed resolution

Add noUi: true to both component manifests, in the same position the other atoms use (directly after description, before props). Canvas then ignores them the way it ignores every other form atom, and the Horizon Aid recipe no longer needs to create and disable them.

The same two files are unflagged in vartheme_bs5, vartheme_bs5_educare and vartheme_bs5_rightup; those are their own issues in their own queues.

Remaining tasks

• ✅ File an issue
• ✅ Addition/Change/Update/Fix
• ✅ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support
• ➖ User Guide Documentation support
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ❌ Update Release Notes
• ❌ Release

User interface changes

• The Checkbox and Input Submit atoms no longer appear in the Canvas component library. They were never usable there - neither carries a prop a content author can set.

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• The Checkbox and Input Submit theme atoms are now flagged noUi, so Canvas no longer offers them as placeable components.