Preserve destructured prop aliases in component library render modules

The component library compiler records public prop names but drops their local destructuring aliases when generating a render method. A component using const { class: classList } = withDefaults(defineProps<Props>(), { class: 'login-input' }) therefore emits const { class = 'login-input' } = this._props(), which is invalid JavaScript. Aliases such as label: caption also leave template references to caption unresolved.

This is present in the framework's real InputGroup.stx sample. The native library build reports success, but the generated package cannot be imported by JavaScript consumers. A standalone Chrome regression reproduces the failure through the emitted ESM modules: neither the supplied-value nor default-value component renders.

The existing alias test checks metadata only. The compiler needs to retain the authored property binding in the executable render scope as well.

Related source qualification: stacksjs/stacks#3029. Do not rewrite consumer components to remove valid aliases.

Acceptance:

• Preserve the public prop name, authored local alias and defaults in generated render code.
• Keep runtime attributes and type/manifest fields named after the public prop.
• Verify supplied values, defaults and reactive attribute changes in a real browser using emitted ESM modules.
• Pass the component library suite, types, lint, full source checks and normal release gates.
• Qualify original published packages and rebuild the real framework sample through normal dependency adoption.

Verified fixed and published. Source fix: 2f11c6b. The public class prop retains its authored classList alias in executable render code; declarations and the manifest retain the public class name. Publication audit completed against fresh registry installations of STX and components 0.2.736, plus the original @stacksjs/hello-world-stx@0.75.334 sample package. Downloaded all three original npm archives, verified SHA1 and SHA512 against registry metadata, and compared every archived file to the installed copy (1,363 / 572 / 37 files respectively); no installed-package edits or workspace links.

Rebuilt the real 13-component Stacks resources/components snapshot with the published STX builder and the framework's existing library options, into an isolated scratch directory. Both that rebuild and the original sample package pass Chrome checks for supplied/default prop aliases, reactive labels, public manifest/type names, native style mutation, native click assignment and real clicks, reactive IDs and highlight on/off branches. Both expose importable public classes and pass a real DOM TypeScript consumer with strict: true and skipLibCheck: false.

Results on Bun 1.4.2: 12 published-package/sample qualification tests passed, 0 failed; 38 maintained source regressions passed, 0 failed. Maintained tests include packages/stx/test/web-components/component-library-alias-browser.test.ts, component-library-native-properties.test.ts and component-library.test.ts, plus the dialog/ref regressions. The exact 0.2.736 release source gate (lint, formatting, release preflight, full source suite) and npm publication passed: https://github.com/stacksjs/stx/actions/runs/40662611298/job/122729098568 and https://github.com/stacksjs/stx/actions/runs/40662611298/job/122735480150 . Latest main CI is also green: https://github.com/stacksjs/stx/actions/runs/40673334028 .

Local audit scripts, qualification.log and archive-receipts.json are retained at /tmp/stx-2126-2129-audit.tZWOJh . No Craft or Stacks source changes were made. This closes the STX compiler issue, not the separate Stacks publisher acceptance issue stacksjs/stacks#3029.