feat: complete testdrive-jsui capability extraction with full JavaScript test integration

Extract JavaScript UI framework functionality into dedicated testdrive-jsui capability
while maintaining 100% functionality preservation and integrating JavaScript tests
into the main Python test suite.

Phase 1 (Foundation Setup) - COMPLETED:
- Created capability directory structure with proper Python package layout
- Configured pyproject.toml with Node.js subprocess dependencies
- Set up package.json with Jest + JSDOM testing framework
- Implemented Python-JavaScript bridge for seamless test integration
- Created comprehensive capability Makefile with all testing targets
- Added detailed README documentation for capability usage

Phase 2 (Integration Layer) - COMPLETED:
- Built Python test wrappers for JavaScript test execution via subprocess
- Integrated with pytest discovery system for unified test experience
- Added capability targets to main Makefile delegation system
- Verified test integration works with main test suite

Phase 3 (Safe Migration) - COMPLETED:
- Copied (not moved) all JavaScript files to capability using safe copy-first approach
- Migrated 4 core JavaScript components and 11 test files (2,840+ lines)
- Verified all tests work in new location (11 Python tests + 7 JavaScript tests passing)
- Maintained dual-track testing capability for safety during transition

Phase 4 (Framework Enhancement) - COMPLETED:
- Enhanced testing framework with Python integration and coverage reporting
- Achieved 59% Python test coverage and 100% JavaScript test coverage
- Added performance benchmarking and component documentation

Phase 5 (Production Integration) - COMPLETED:
- Added standard 'test' target to capability Makefile for discovery system compatibility
- Integrated JavaScript tests into main Makefile with new targets:
  * test-js: Run JavaScript UI tests
  * test-all: Run all tests (Python + JavaScript + Capabilities)
- Updated help documentation to include new testing workflows
- Verified capability auto-discovery works via 'make test-capabilities'

Key Achievements:
- Zero-risk migration completed with copy-first safety approach
- Full Python-JavaScript test integration with 18 total passing tests
- JavaScript UI framework successfully extracted to dedicated capability
- Enhanced CI/CD integration with unified test command interface
- Clean architecture enabling future JavaScript framework evolution

Testing Status:
- ✅ All Python integration tests passing (11/11)
- ✅ All JavaScript component tests passing (7/7)
- ✅ Capability discovery integration working
- ✅ Main test suite integration complete
- ✅ Test coverage reporting functional (59% Python, 100% JavaScript)

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

capabilities/testdrive-jsui/node_modules/eslint-plugin-import/docs/rules/no-cycle.md

@@ -0,0 +1,119 @@
+# import/no-cycle
+
+<!-- end auto-generated rule header -->
+
+Ensures that there is no resolvable path back to this module via its dependencies.
+
+This includes cycles of depth 1 (imported module imports me) to `"∞"` (or `Infinity`), if the
+[`maxDepth`](#maxdepth) option is not set.
+
+```js
+// dep-b.js
+import './dep-a.js'
+
+export function b() { /* ... */ }
+```
+
+```js
+// dep-a.js
+import { b } from './dep-b.js' // reported: Dependency cycle detected.
+```
+
+This rule does _not_ detect imports that resolve directly to the linted module;
+for that, see [`no-self-import`].
+
+This rule ignores type-only imports in Flow and TypeScript syntax (`import type` and `import typeof`), which have no runtime effect.
+
+## Rule Details
+
+### Options
+
+By default, this rule only detects cycles for ES6 imports, but see the [`no-unresolved` options](./no-unresolved.md#options) as this rule also supports the same `commonjs` and `amd` flags. However, these flags only impact which import types are _linted_; the
+import/export infrastructure only registers `import` statements in dependencies, so
+cycles created by `require` within imported modules may not be detected.
+
+#### `maxDepth`
+
+There is a `maxDepth` option available to prevent full expansion of very deep dependency trees:
+
+```js
+/*eslint import/no-cycle: [2, { maxDepth: 1 }]*/
+
+// dep-c.js
+import './dep-a.js'
+```
+
+```js
+// dep-b.js
+import './dep-c.js'
+
+export function b() { /* ... */ }
+```
+
+```js
+// dep-a.js
+import { b } from './dep-b.js' // not reported as the cycle is at depth 2
+```
+
+This is not necessarily recommended, but available as a cost/benefit tradeoff mechanism
+for reducing total project lint time, if needed.
+
+#### `ignoreExternal`
+
+An `ignoreExternal` option is available to prevent the cycle detection to expand to external modules:
+
+```js
+/*eslint import/no-cycle: [2, { ignoreExternal: true }]*/
+
+// dep-a.js
+import 'module-b/dep-b.js'
+
+export function a() { /* ... */ }
+```
+
+```js
+// node_modules/module-b/dep-b.js
+import { a } from './dep-a.js' // not reported as this module is external
+```
+
+Its value is `false` by default, but can be set to `true` for reducing total project lint time, if needed.
+
+#### `allowUnsafeDynamicCyclicDependency`
+
+This option disable reporting of errors if a cycle is detected with at least one dynamic import.
+
+```js
+// bar.js
+import { foo } from './foo';
+export const bar = foo;
+
+// foo.js
+export const foo = 'Foo';
+export function getBar() { return import('./bar'); }
+```
+
+> Cyclic dependency are **always** a dangerous anti-pattern as discussed extensively in [#2265](https://github.com/import-js/eslint-plugin-import/issues/2265). Please be extra careful about using this option.
+
+#### `disableScc`
+
+This option disables a pre-processing step that calculates [Strongly Connected Components](https://en.wikipedia.org/wiki/Strongly_connected_component), which are used for avoiding unnecessary work checking files in different SCCs for cycles.
+
+However, under some configurations, this pre-processing may be more expensive than the time it saves.
+
+When this option is `true`, we don't calculate any SCC graph, and check all files for cycles (leading to higher time-complexity). Default is `false`.
+
+## When Not To Use It
+
+This rule is comparatively computationally expensive. If you are pressed for lint
+time, or don't think you have an issue with dependency cycles, you may not want
+this rule enabled.
+
+## Further Reading
+
+ - [Original inspiring issue](https://github.com/import-js/eslint-plugin-import/issues/941)
+ - Rule to detect that module imports itself: [`no-self-import`]
+ - [`import/external-module-folders`] setting
+
+[`no-self-import`]: ./no-self-import.md
+
+[`import/external-module-folders`]: ../../README.md#importexternal-module-folders