[Feature Request] Import workspace packages by name, and audit the packages an app imports #1140

Description

Two related gaps for monorepos where packages own their env vars (the per-package schema layout from the monorepo guide):

1. @import() only takes file paths, so an app imports each workspace package's schema by relative path: # @import(../../packages/db/).
2. varlock audit only scans the directories it is given. An app whose code reaches a package's code through a workspace import has no way to audit that package's env reads against the app's schema, so a package schema the app forgot to import goes unnoticed.

Motivation

In a Bun monorepo with several apps and packages, each package declares its own vars and each app imports the schemas of the packages it uses. The relative paths duplicate what package.json already says (the app depends on @acme/db), and break when a package moves. For the audit we wrote a 78-line script that walks each app's module graph (Bun.Transpiler.scanImports, Bun.resolveSync), collects the workspace packages it reaches, and runs varlock audit <app> <package dirs...> per app. That script is the one piece of custom env tooling left.

Proposed Solution

• Let @import() take a package name and resolve it the way the runtime would, from the importing file: # @import(@acme/db) imports that package's directory (its .env.schema plus env files), the same as @import(../../packages/db/) today. pick/omit/enabled/allowMissing work as for paths.
• With that, varlock audit knows which package directories belong to a schema and can scan them alongside the app's own code, so a var read in @acme/db but missing from the app's resolved schema is reported. A flag or root decorator could turn this on (for example varlock audit --imports).

Alternatives

• Keep relative paths and a hand-written import-graph script per repo (what we do now).
• package.json varlock.loadPath with tags from a single root schema; this loses per-package ownership of vars.

Additional Information

varlock flatten already rewrites import paths for container builds, so package-name imports would need the same treatment there.