fix(aitools): non-zero exit when discover-schema has any failed table

[jamesbroadhead]

Summary

databricks aitools tools discover-schema TABLE... rendered per-table failures into stdout but always returned nil from RunE. Even when every table failed, the process exited 0, so scripts and CI couldn't detect failure without grepping output for "Error discovering " — exactly the kind of err.Error() string-matching the repo's style guide forbids.

Extract the loop into runDiscoverSchemas which returns (output, anyFailed). RunE prints the output and returns root.ErrAlreadyPrinted when anyFailed is true so cobra produces a non-zero exit without re-printing the per-table errors. Behavior preserved: one bad table still doesn't abort the others.

Spotted via multi-model code review on #4917 (GPT 5.4). Pre-existing in #5097, not introduced by #4917 — sending as a separate small fix per the "keep PRs focused" rule.

Test plan

• go test ./experimental/aitools/cmd/ (new tests: TestRunDiscoverSchemasFlagsTableFailureForExitCode, TestRunDiscoverSchemasAllSucceedReturnsFalse).
• Manual: databricks aitools tools discover-schema doesnt.exist.foo; echo $? should now print 1.
• Manual: a successful run still prints 0.

This pull request and its description were written by Isaac.

[simonfaltum]

Looks good to me. This matches the nearby aitools pattern of printing the detailed failure once, then returning root.ErrAlreadyPrinted so scripts get a non-zero exit without an extra Cobra error line.

One scope question: should sample-data/null-count probe failures inside a successfully described table also make the command exit non-zero? Today discoverTable renders those as SAMPLE DATA: Error - ... / NULL COUNTS: Error - ... but still returns nil, so this PR only covers full table-discovery failures. That may be intentional, but I wanted to call it out explicitly.