Fix agent process crash from a bad bundle-filter scalar value

Problem/Motivation

The ai_agents_views:update_view_handler_option tool (UpdateViewHandlerOptions::execute()) can crash the entire PHP process - not just the one tool call, and not even catchable as a normal PHP exception - when a bundle (content type or vocabulary) filter's value is set to a scalar string instead of the keyed map Drupal core's own Bundle filter plugin expects.

Setting a bundle/type filter's value to something like {"value":"tags"} (a bare string) instead of the correct {"value":{"tags":"tags"}} (a keyed map of bundle machine name to itself) is a very easy mistake for an LLM to make, since a single-bundle filter reads naturally as "just the one string." Before this fix, that mistake didn't produce a tool error - it terminated the whole agent process with an uncaught fatal.

Steps to reproduce

1. Add a bundle-type filter handler to a View (e.g. node's type, or taxonomy_term's vid).
2. Call ai_agents_views:update_view_handler_option to set that filter's options to a bare scalar string value, e.g. {"value":"tags"}.

Expected: a normal tool result explaining the value could not be applied.

Actual (before this fix): an uncaught \TypeError crashes the whole PHP process.

Root cause

execute() passed the merged options straight to $view_executable->setHandler() / save() with no error handling at all:

$view_executable->setHandler($display_id, $handler_type, $field_id, $options + $configuration);
$view_executable->mergeDefaults();
$this->addViewTag($view, 'ai_agents_views_updated');
$view_executable->save();

Drupal core's Bundle filter plugin (Drupal\views\Plugin\views\filter\Bundle) does not validate the shape of $this->value before save() calculates the View's config dependencies. Its calculateDependencies() calls array_keys($this->value) - and when the LLM has set value to a plain string instead of an array, PHP's array_keys() throws a \TypeError, not an \Exception. With zero error handling around the save() call, this \TypeError propagates all the way out and crashes the process.

(A plain list, e.g. {"value":["tags"]}, hits a different, quieter failure mode: array_keys() on a list returns integer indexes rather than bundle names, so the filter silently registers the wrong config dependency instead of crashing - not covered by this specific fix, but documented in the system prompt alongside the correct shape.)

Proposed resolution

Wrap the handler save in try/catch, using \Throwable rather than \Exception specifically because the real failure mode here is a \TypeError:

try {
  $view_executable->setHandler($display_id, $handler_type, $field_id, $options + $configuration);
  $view_executable->mergeDefaults();
  $this->addViewTag($view, 'ai_agents_views_updated');
  $view_executable->save();
}
catch (\Throwable $e) {
  $this->list = "The options could not be applied: " . $e->getMessage();
  $this->list .= "\nThe current options for '$field_id' are: " . Json::encode($configuration);
  return;
}

Also documents the correct keyed-map shape for bundle/type filters in the system prompt, with an explicit warning against both the bare-string and plain-list mistakes.

Remaining tasks

• File this issue on drupal.org.
• Open an MR with the fix above.

Test coverage added locally

Regression test testScalarValueForBundleFilterDoesNotCrash() in tests/src/Kernel/Plugin/AiFunctionCall/UpdateViewHandlerOptionsTest.php reproduces the exact scalar-value mistake on a taxonomy_term view's vid filter and asserts a normal, readable tool result instead of an uncaught error terminating the test process.

New Integration test ConfigureBundleFilterTest::testScalarValueIsRejected() (tests/src/Kernel/Integration/ConfigureBundleFilterTest.php) reproduces the same mistake through the real tool chain (create the handler, then update it), and additionally confirms the rejected scalar value was never saved into the View's config at all - not just that the process didn't crash.

Full suite with this fix applied (isolated on its own branch): 11/11 kernel tests passing (97 assertions) across both test files, no failures.

API changes

None. This is a bug fix to existing, already-broken behavior - no new context parameters, no signature changes, no config schema changes.