Description

The using directive does not bring stdlib module exports (constants, structs, maps, variables) into file scope. Users must always use the full module prefix even after declaring using <module>.

Steps to Reproduce

Constants (@http, @os):

import @std
import @http
using std
using http

do main() {
    println("${OK}")        // Error: undefined variable 'OK'
    println("${http.OK}")   // Works: 200
}

import @std
import @os
using std
using os

do main() {
    println("${MAC_OS}")      // Error: undefined variable 'MAC_OS'
    println("${os.MAC_OS}")   // Works: 0
}

Structs/Types (@io, @db, etc.):

import @std
import @io
using std
using io

do main() {
    // If io exports structs/types, they would also require prefix
}

Expected Behavior

After using <module>, the module's exported constants, structs, maps, and variables should be accessible without the module prefix, consistent with how using std makes functions like println accessible without std.println.

Actual Behavior

Only functions appear to be brought into scope by using. Constants and other exports always require the full module prefix.

Affected Modules

All stdlib modules with non-function exports:

• @http - OK, CREATED, NOT_FOUND, BAD_REQUEST, etc.
• @os - MAC_OS, LINUX, WINDOWS, CURRENT_OS
• @io - any exported types/structs
• @db - any exported types/structs
• @time - any exported constants
• Other stdlib modules with constants or type exports

Additional Context

Discovered during review of PR #907 (HTTP status code constants). The new HTTP constants follow the existing pattern used by @os constants, confirming this is a pre-existing limitation in the module system rather than a regression.

The fix likely involves updating how using resolves non-function exports in the interpreter's scope resolution logic.