Member walks silently drop unrecognized declarations (nested types, typealiases, indexed subscripts)

Found while implementing #14. The struct / class / enum / extension member walks match the declaration kinds they know (var, init, func, subscript(dynamicMember:)) with an if / else-if chain that has no final else — every other member declaration is dropped without a sound, and the failure surfaces later as a misleading downstream error.

Reproduction (current main):

struct Outer {
    struct Inner { var x: Int }
    typealias ID = Int
}
let i = Outer.Inner(x: 1)
print(i.x)

error: type 'Outer' has no member 'Inner'

The declaration loaded fine — the nested struct Inner and the typealias ID were both silently discarded — and the error the user gets points at the use site with a claim that contradicts the source they can see. That is exactly the plausible-wrong-behavior class the issue #8 work (loud divergences) and the attribute preflight exist to prevent: a boundary error at the declaration would say "the interpreter can't do this yet"; the current error says "your code is wrong" when it isn't.

Silently dropped today (verified against the walk in Interpreter+Structs.swift; the class/enum/extension walks share the shape):

• nested type declarations (struct, class, enum, actor inside a type)
• typealias members
• indexed subscripts — the subscriptDecl branch keeps only the subscript(dynamicMember:) shape and silently ignores subscript(_ i: Int) (declaring one succeeds; using it then fails confusingly)
• protocol declarations nested in a type

Freestanding macros in member position (struct S { #foo(\"x\") }) were on this list too; the #14 PR makes that one loud (rejectMacroMember), and its pattern is the suggested fix here: keep the walks' known branches, add a final else that throws RuntimeError.unsupported("declaration \(decl.syntaxNodeType) in member position", at: …) so unhandled member kinds fail at the declaration with an honest boundary message. Nested-type support can then be added later, kind by kind, without users ever passing through the misleading state.

Start in Interpreter+Structs.swift, then inspect the shared member walks for classes, enums, and extensions. Compare their known declaration branches with the rejectMacroMember pattern from #14 and run the nested-type and indexed-subscript reproductions. Done means every currently unsupported member declaration fails at its declaration with an honest RuntimeError rather than disappearing silently.