…ly introduced problem (#260499)

## Summary

Follow-up to #260280, addressing the edge case raised in [this review
comment](https://github.com/elastic/kibana/pull/260280/changes/BASE..8b520af6534a998b849dd3567b3b659c470e60ea#r3016163498).

### The bug

The pre-existing vs. newly-introduced classification in
`validateNameTitleFieldTypesExistingType` was based on whether the field
*key* was present in the baseline snapshot (`'properties.name.type' in
from.mappings`). This correctly catches `absent → keyword`, but silently
misclassifies `text → keyword` as pre-existing — because the key is
already in `from.mappings`, even though the field was previously valid.

The result: a developer who downgrades a `name`/`title` field from
`text` to `keyword` gets no warning and no failure from the CI check.

### The fix

Both `preExisting` and `newlyIntroduced` are now derived from the set of
fields that were **already invalid in `from`**, not merely present:

```ts
const alreadyInvalidInFrom = new Set(
  getInvalidNameTitleFields(from).map(({ fieldName }) => fieldName)
);
const preExisting     = invalidInTo.filter(({ fieldName }) =>  alreadyInvalidInFrom.has(fieldName));
const newlyIntroduced = invalidInTo.filter(({ fieldName }) => !alreadyInvalidInFrom.has(fieldName));
```

This handles all four scenarios correctly:

| `from` type | `to` type | Result |
|---|---|---|
| absent | `keyword` | ❌ fail (newly introduced) |
| `text` | `keyword` | ❌ fail (newly introduced — was this PR's bug) |
| `keyword` | `keyword` | ⚠️ warn (pre-existing, cannot be fixed without
reindex) |
| `keyword` | `text` | ✅ nothing (fixed) |

## Test plan

- [ ] New test `'should throw when a name or title field is downgraded
from text to keyword'` in `existing_type.test.ts` covers the regression
case
- [ ] All 40 tests in the `validate_changes` suite pass

Made with [Cursor](https://cursor.com)

…mportable/exportable SO types (elastic#260280)

## Summary

Closes elastic/kibana-team#3162

The \`validateNameTitleFieldTypes\` check in
\`kbn-check-saved-objects-cli\` enforces that any SO type with a
\`name\` or \`title\` mapping field must use \`type: text\`, citing
Search API compatibility. There are two distinct cases where the check
was incorrect:

### Case 1: Types not searchable via the management page

The check was applied unconditionally to all SO types, but the Saved
Objects management page search only queries types where
\`management.importableAndExportable === true\`. The registry treats the
absence of that flag as \`false\`, so types without it set are never
included in management search and the full-text requirement does not
apply to them.

Flagging such types also creates pressure to change \`keyword\` →
\`text\`, which is a **breaking Elasticsearch mapping change** (reindex
required) that is entirely unnecessary.

Note: the \`hidden\` flag alone is **not** the right exemption criterion
— the management find route explicitly includes hidden types that are
also \`importableAndExportable: true\` (via \`includedHiddenTypes\`), so
those remain subject to the check.

### Case 2: Pre-existing keyword fields from shipped model versions

Even for importable/exportable types, if \`name\` or \`title\` was
already shipped as \`keyword\` in a previous model version, **there is
nothing the developer can do to fix it** without a full reindex. Failing
the CI check in this case blocks the PR with no actionable resolution.

## Changes

- Split \`validateNameTitleFieldTypes\` into two focused functions:
- \`validateNameTitleFieldTypesNewType\` (in \`new_type_utils.ts\`) —
throws for any wrong field type on importable/exportable types; no
baseline exists for new types so the full error always applies
- \`validateNameTitleFieldTypesExistingType\` (in
\`existing_type_utils.ts\`) — warns for pre-existing wrong field types,
fails only for newly introduced ones
- Shared helpers \`getInvalidNameTitleFields\` and
\`isSearchableViaManagement\` extracted to \`common_utils.ts\`
- Exemption condition uses \`!== true\` (not \`=== false\`) to also
cover types where \`management\` is absent, matching the registry's \`??
false\` default
- \`createMockType\` in tests now defaults to \`importableAndExportable:
true\` so the positive (participates-in-management-search) path is
exercised correctly
- Tests updated: exemption test covers \`importableAndExportable:
false\`; a new test confirms that hidden types with
\`importableAndExportable: true\` are still subject to the check

## Context

This was first surfaced by
elastic#260095, which adds model version
2 to \`gap_auto_fill_scheduler\` — a type with
\`importableAndExportable\` not set to \`true\` and a pre-existing
\`name: keyword\` mapping from model version 1.

## Test plan

- [ ] Existing tests in \`new_type.test.ts\` still pass
- [ ] Tests in \`existing_type.test.ts\` confirm: warning for
pre-existing keyword fields, fail for newly introduced ones, exempt for
non-importable/exportable types, and fail for hidden types that are
importable/exportable

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…ly introduced problem (elastic#260499)

## Summary

Follow-up to elastic#260280, addressing the edge case raised in [this review
comment](https://github.com/elastic/kibana/pull/260280/changes/BASE..8b520af6534a998b849dd3567b3b659c470e60ea#r3016163498).

### The bug

The pre-existing vs. newly-introduced classification in
`validateNameTitleFieldTypesExistingType` was based on whether the field
*key* was present in the baseline snapshot (`'properties.name.type' in
from.mappings`). This correctly catches `absent → keyword`, but silently
misclassifies `text → keyword` as pre-existing — because the key is
already in `from.mappings`, even though the field was previously valid.

The result: a developer who downgrades a `name`/`title` field from
`text` to `keyword` gets no warning and no failure from the CI check.

### The fix

Both `preExisting` and `newlyIntroduced` are now derived from the set of
fields that were **already invalid in `from`**, not merely present:

```ts
const alreadyInvalidInFrom = new Set(
  getInvalidNameTitleFields(from).map(({ fieldName }) => fieldName)
);
const preExisting     = invalidInTo.filter(({ fieldName }) =>  alreadyInvalidInFrom.has(fieldName));
const newlyIntroduced = invalidInTo.filter(({ fieldName }) => !alreadyInvalidInFrom.has(fieldName));
```

This handles all four scenarios correctly:

| `from` type | `to` type | Result |
|---|---|---|
| absent | `keyword` | ❌ fail (newly introduced) |
| `text` | `keyword` | ❌ fail (newly introduced — was this PR's bug) |
| `keyword` | `keyword` | ⚠️ warn (pre-existing, cannot be fixed without
reindex) |
| `keyword` | `text` | ✅ nothing (fixed) |

## Test plan

- [ ] New test `'should throw when a name or title field is downgraded
from text to keyword'` in `existing_type.test.ts` covers the regression
case
- [ ] All 40 tests in the `validate_changes` suite pass

Made with [Cursor](https://cursor.com)

…ly introduced problem (elastic#260499)

## Summary

Follow-up to elastic#260280, addressing the edge case raised in [this review
comment](https://github.com/elastic/kibana/pull/260280/changes/BASE..8b520af6534a998b849dd3567b3b659c470e60ea#r3016163498).

### The bug

The pre-existing vs. newly-introduced classification in
`validateNameTitleFieldTypesExistingType` was based on whether the field
*key* was present in the baseline snapshot (`'properties.name.type' in
from.mappings`). This correctly catches `absent → keyword`, but silently
misclassifies `text → keyword` as pre-existing — because the key is
already in `from.mappings`, even though the field was previously valid.

The result: a developer who downgrades a `name`/`title` field from
`text` to `keyword` gets no warning and no failure from the CI check.

### The fix

Both `preExisting` and `newlyIntroduced` are now derived from the set of
fields that were **already invalid in `from`**, not merely present:

```ts
const alreadyInvalidInFrom = new Set(
  getInvalidNameTitleFields(from).map(({ fieldName }) => fieldName)
);
const preExisting     = invalidInTo.filter(({ fieldName }) =>  alreadyInvalidInFrom.has(fieldName));
const newlyIntroduced = invalidInTo.filter(({ fieldName }) => !alreadyInvalidInFrom.has(fieldName));
```

This handles all four scenarios correctly:

| `from` type | `to` type | Result |
|---|---|---|
| absent | `keyword` | ❌ fail (newly introduced) |
| `text` | `keyword` | ❌ fail (newly introduced — was this PR's bug) |
| `keyword` | `keyword` | ⚠️ warn (pre-existing, cannot be fixed without
reindex) |
| `keyword` | `text` | ✅ nothing (fixed) |

## Test plan

- [ ] New test `'should throw when a name or title field is downgraded
from text to keyword'` in `existing_type.test.ts` covers the regression
case
- [ ] All 40 tests in the `validate_changes` suite pass

Made with [Cursor](https://cursor.com)

…mportable/exportable SO types (elastic#260280)

## Summary

Closes elastic/kibana-team#3162

The \`validateNameTitleFieldTypes\` check in
\`kbn-check-saved-objects-cli\` enforces that any SO type with a
\`name\` or \`title\` mapping field must use \`type: text\`, citing
Search API compatibility. There are two distinct cases where the check
was incorrect:

### Case 1: Types not searchable via the management page

The check was applied unconditionally to all SO types, but the Saved
Objects management page search only queries types where
\`management.importableAndExportable === true\`. The registry treats the
absence of that flag as \`false\`, so types without it set are never
included in management search and the full-text requirement does not
apply to them.

Flagging such types also creates pressure to change \`keyword\` →
\`text\`, which is a **breaking Elasticsearch mapping change** (reindex
required) that is entirely unnecessary.

Note: the \`hidden\` flag alone is **not** the right exemption criterion
— the management find route explicitly includes hidden types that are
also \`importableAndExportable: true\` (via \`includedHiddenTypes\`), so
those remain subject to the check.

### Case 2: Pre-existing keyword fields from shipped model versions

Even for importable/exportable types, if \`name\` or \`title\` was
already shipped as \`keyword\` in a previous model version, **there is
nothing the developer can do to fix it** without a full reindex. Failing
the CI check in this case blocks the PR with no actionable resolution.

## Changes

- Split \`validateNameTitleFieldTypes\` into two focused functions:
- \`validateNameTitleFieldTypesNewType\` (in \`new_type_utils.ts\`) —
throws for any wrong field type on importable/exportable types; no
baseline exists for new types so the full error always applies
- \`validateNameTitleFieldTypesExistingType\` (in
\`existing_type_utils.ts\`) — warns for pre-existing wrong field types,
fails only for newly introduced ones
- Shared helpers \`getInvalidNameTitleFields\` and
\`isSearchableViaManagement\` extracted to \`common_utils.ts\`
- Exemption condition uses \`!== true\` (not \`=== false\`) to also
cover types where \`management\` is absent, matching the registry's \`??
false\` default
- \`createMockType\` in tests now defaults to \`importableAndExportable:
true\` so the positive (participates-in-management-search) path is
exercised correctly
- Tests updated: exemption test covers \`importableAndExportable:
false\`; a new test confirms that hidden types with
\`importableAndExportable: true\` are still subject to the check

## Context

This was first surfaced by
elastic#260095, which adds model version
2 to \`gap_auto_fill_scheduler\` — a type with
\`importableAndExportable\` not set to \`true\` and a pre-existing
\`name: keyword\` mapping from model version 1.

## Test plan

- [ ] Existing tests in \`new_type.test.ts\` still pass
- [ ] Tests in \`existing_type.test.ts\` confirm: warning for
pre-existing keyword fields, fail for newly introduced ones, exempt for
non-importable/exportable types, and fail for hidden types that are
importable/exportable

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…ly introduced problem (elastic#260499)

## Summary

Follow-up to elastic#260280, addressing the edge case raised in [this review
comment](https://github.com/elastic/kibana/pull/260280/changes/BASE..8b520af6534a998b849dd3567b3b659c470e60ea#r3016163498).

### The bug

The pre-existing vs. newly-introduced classification in
`validateNameTitleFieldTypesExistingType` was based on whether the field
*key* was present in the baseline snapshot (`'properties.name.type' in
from.mappings`). This correctly catches `absent → keyword`, but silently
misclassifies `text → keyword` as pre-existing — because the key is
already in `from.mappings`, even though the field was previously valid.

The result: a developer who downgrades a `name`/`title` field from
`text` to `keyword` gets no warning and no failure from the CI check.

### The fix

Both `preExisting` and `newlyIntroduced` are now derived from the set of
fields that were **already invalid in `from`**, not merely present:

```ts
const alreadyInvalidInFrom = new Set(
  getInvalidNameTitleFields(from).map(({ fieldName }) => fieldName)
);
const preExisting     = invalidInTo.filter(({ fieldName }) =>  alreadyInvalidInFrom.has(fieldName));
const newlyIntroduced = invalidInTo.filter(({ fieldName }) => !alreadyInvalidInFrom.has(fieldName));
```

This handles all four scenarios correctly:

| `from` type | `to` type | Result |
|---|---|---|
| absent | `keyword` | ❌ fail (newly introduced) |
| `text` | `keyword` | ❌ fail (newly introduced — was this PR's bug) |
| `keyword` | `keyword` | ⚠️ warn (pre-existing, cannot be fixed without
reindex) |
| `keyword` | `text` | ✅ nothing (fixed) |

## Test plan

- [ ] New test `'should throw when a name or title field is downgraded
from text to keyword'` in `existing_type.test.ts` covers the regression
case
- [ ] All 40 tests in the `validate_changes` suite pass

Made with [Cursor](https://cursor.com)