chore: add missing keywords to two array/base/assert packages

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• Adds the test and validate keywords to array/base/assert/contains and array/base/assert/is-sorted-ascending to bring them in line with the rest of the array/base/assert/* namespace.

Namespace summary

• Members analyzed: 26 non-autogenerated packages in @stdlib/array/base/assert/.
• Features analyzed: file tree, package.json shape, README section list, manifest.json shape, test/benchmark/example file naming, JSDoc shape, error construction, dependency graph.
• Features with a clear majority (≥75%): test keyword (24/26 = 92%), validate keyword (24/26 = 92%), file-tree presence of lib/index.js, lib/main.js, benchmark/, examples/, test/, docs/, docs/types/, docs/repl.txt (26/26), returned type boolean (26/26), @example present in exported JSDoc (26/26), error construction none (26/26 - all base/ packages skip validation).
• Features excluded (no clear majority): benchmark file naming (73% benchmark.js, split by whether the function iterates over an array); README ## section list (65% [Usage, Examples] vs 35% [Usage, Notes, Examples]); assignment form in main.js (58% function foo() {} vs 42% var isX = contains(dtypes(...)), correlated with whether the function is factory-produced).

array/base/assert/contains

Add test and validate to the keywords array. 24 of the 26 packages in this namespace carry both — the sibling has-* assertions (has-equal-values, has-same-values, ...) share the same functional shape as contains (test-a-property-of-an-array) and list both keywords. contains is one of two holdouts.

array/base/assert/is-sorted-ascending

Add test and validate to the keywords array. Same rationale: is-sorted-ascending tests an array-level property and matches the has-* sibling shape, but currently omits both keywords. The other 24 packages in the namespace include them.

Related Issues

Does this pull request have any related issues?

None.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

Validation

• Structural extraction. Filesystem walk over all 26 packages: file tree, package.json top-level/scripts/keywords, manifest.json shape, README ##/### heading sequence, test/benchmark/example filename lists.
• Semantic extraction. Per-package scan of lib/main.js and lib/index.js for public signature, exported JSDoc block (@param/@returns/@throws/@example), error-construction form, and dependency set (require() calls). Semantic space is uniform: 0 throw statements across the namespace (the sole exception is contains/lib/factory.js, which is public API and intentional), 0 lib/validate.js files, and all 26 exported functions return boolean. This is expected for base/ packages, which trust their inputs.
• Drift finding. Only the test and validate keyword additions in contains and is-sorted-ascending cleared the 75% majority threshold and all pre-validation gates (no open-PR collision, no autogenerated files touched, ≥90% ecosystem-wide presence for the added keywords in assert/* namespaces, materiality satisfied by batching two outliers).
• Deliberately excluded. test.factory.js/test.main.js in contains (factory sub-API is intentional; other 25 packages have no factory to test). benchmark.length.js/benchmark.accessors.length.js on the has-* cluster and on contains/is-sorted-ascending (semantic-driven: only packages that iterate over an array benchmark across lengths). README ## Notes section presence (no majority - 65/35 split). __stdlib__ package.json key (54% presence - no majority; tracks a dtype-name-check subgroup). The five is-*array packages using the stdassert/assertion keyword cluster instead of stdtypes/types (81/19 split, but the 5 form a coherent subgroup by design).

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

This PR was authored by Claude Code running a cross-package drift-detection routine over @stdlib/array/base/assert/*. The routine extracted structural and semantic features from all 26 non-autogenerated members, identified test/validate keyword presence (92% majority) as the sole finding surviving the drift filters, and applied the mechanical package.json edits.

---

@stdlib-js/reviewers

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
array/base/assert/contains	$\\color{green}227/227$ $\\color{green}+100.00\\%$	$\\color{green}23/23$ $\\color{green}+100.00\\%$	$\\color{green}4/4$ $\\color{green}+100.00\\%$	$\\color{green}227/227$ $\\color{green}+100.00\\%$
array/base/assert/is-sorted-ascending	$\\color{green}140/140$ $\\color{green}+100.00\\%$	$\\color{green}9/9$ $\\color{green}+100.00\\%$	$\\color{green}1/1$ $\\color{green}+100.00\\%$	$\\color{green}140/140$ $\\color{green}+100.00\\%$

The above coverage report was generated for the changes in this PR.