fix: resolve lodash functions via named entry points, not named imports

[cdmren]

Fixes #270

src/index.ts, src/formatting.ts, and src/path.ts imported functions from lodash with named imports (e.g. import {reduce, map as _map, find} from 'lodash'). lodash is CommonJS and has no static named exports, so this breaks under any consumer that resolves it through native ESM — e.g. Vitest — now that this package declares "type": "module". Bundler-based tooling (Vite, esbuild) and tsc under looser moduleResolution settings tolerate the interop, which is why this only surfaced in downstream test suites, not builds or typechecks.

Switched each import to its own entry point instead (import reduce from 'lodash/reduce.js'), with an explicit .js extension — required for this repo's own tsc build under moduleResolution: NodeNext, which needs fully-specified ESM specifiers. src/index.test.ts and src/test-helper.ts had the same pattern (forEach, identity) and got the same fix, since they'd hit the same failure if this package's own test suite were consumed the same way.

Verified locally: pnpm build and pnpm test (76/76) pass here, and — more importantly — linking this branch into freckle/megarepo's frontend/platform/console (which was failing exactly this way after bumping to @freckle/parser@3.0.0) and running its full Vitest suite now passes 570/570, where it previously failed with the SyntaxError: Named export 'map' not found error described in #270.

dist/ is rebuilt and committed alongside src/, per this repo's own check-git-clean.sh convention.

• Claude

[github-actions]

PR checklist

• Version in package.json is updated according to semver policy.
• Built dist/ reflects all changes in PR prior to merge.

[joris974]

Good. I am pretty sure we can remove lodash and use native JS functions for many of the usecase here (map, find, reduce, forEach). identity is an interesting one I haven't used before