native: import directly from shared src instead of bundle

[davidisaaclee]

• pnpm run dev:shared is no longer necessary
• While developing app, changing code in shared will now trigger a (working) reload of the app – no more unexpected undefined
• Importing from @tloncorp/shared/dist/* is no longer allowed: imports of those subpackages must now be (1) declared in the exports in shared/package.json, and (2) imported using the alias from exports, e.g. @tloncorp/shared/db.

All packages typecheck and build, but some tests are failing – e.g. packages/shared/src/db/queries.test.ts.

• These failures manifest as a cryptic Vitest Rollup error: Error: Expected ';', '}' or <eof>.
• I ended up debugging by searching for the offending lines, which didn't show any sort of pattern, except that they were imports from a file in the same package.
• Based on a hunch, I ran a dependency cycle checker:
  and those are only the cycles reachable from that file. gist
• At least one of these cycles (packages/shared/src/urbit/channel.ts -> packages/shared/src/urbit/content.ts) requires large careful code movement to fix (or maybe just merge the two files? I think I don't have context on the organization here)

I don't have a great understanding of why this is newly a problem: my guess is that we were kind of "dynamically importing" the bundled code when running tests previously (i.e. each file in the bundle had a dynamic require to another file in the bundle): since we're now doing "static imports" and need to resolve dependencies up front (to make an esm bundle?), Vitest's Rollup is blowing up at the cycles.

---

I think the main change in DX around skipping bundling shared was good enough here to open this PR; I'm going to look for workarounds on the dependency cycle issue; but we should really try to remove these cycles, as I think they are preventing more efficient bundling and potentially causing ghostly bugs.

[davidisaaclee]

• Running dpdm --transform (iiuc, transform TS first, then look for cycles, then report based on sourcemap) makes the cycle list much smaller (just two easily-fixed entries); however, applying this patch (5aba3bf) to this branch does not fix the test failures
• I don't know why --transform is only reporting this small number of cycles: tracing manually, one can see cycles like api/postsApi.ts -> db[/index.ts] -> db/modelBuilders.ts -> api/postsApi.ts

This will probably require a lot of code movement to fix, but I'm trying to minimize the movement to get this PR in. Going forward, I think we should enforce the following dependency layers using @typescript-eslint/no-restricted-imports rules (which I think will also require us to migrate our eslint config to a modern format):

store   (no offending imports because it can do what it wants)
logic   (0 offending imports)
api     (2 offending imports)
db      (10 offending imports)
urbit   (3 offending imports)

• higher directories can import from lower directories, but not the other way around
• offending imports found by running e.g. rg "import .+ from '../(?:store|logic|api|db)" packages/shared/src/urbit/** --stats to check imports in urbit from one of store|logic|api|db

lmk if that looks right, I obviously have the least experience with this code