BridgeJS: Support nested @JS types inside structs and classes

[krodak]

Overview

Fixes #667. @JS structs and classes nested inside other @JS structs or classes now generate correct Swift code with fully qualified type names and unique ABI symbols.

The import side (@JSClass/@JSGetter macros) already handles nested types correctly — the Swift compiler provides the fully qualified type for extension generation. The bug was on the export side (@JS attribute), where the codegen pipeline produced broken code for nested types.

Previously, a nested type like User.Stats would generate code referencing bare Stats — wrong Swift name, wrong ABI symbols, and potential collisions with top-level types of the same name.

@JS class User {
    @JS func getName() -> String { "test" }
    @JS struct Stats {
        var health: Int
        var score: Double
    }
}

Before:

extension Stats: _BridgedSwiftStruct { ... }         // wrong
@_cdecl("bjs_Stats_init") ...                         // collision risk

After:

extension User.Stats: _BridgedSwiftStruct { ... }     // correct
@_cdecl("bjs_User_Stats_init") ...                     // unique

1. computeSwiftCallName — now walks parent StructDeclSyntax and ClassDeclSyntax in addition to EnumDeclSyntax, producing "User.Stats" instead of "Stats".

2. computeParentTypeNamespace + effectiveNamespace — computes the parent struct/class path and merges it with the resolved enum namespace for ABI name uniqueness.

3. Struct/class visitors — use effective namespace when creating ExportedStruct / ExportedClass, keeping keys and ABI names collision-free.

Existing enum namespace nesting continues to work unchanged.

Tests:

• New NestedType.swift export-side test fixture with codegen + link snapshots
• New nestedJSClassStruct macro test confirming the import side already works
• Existing nested type diagnostic tests updated to assert success