chore: regenerate lock files

[devin-ai-integration]

Summary

Regenerated the repo's lock files from scratch after the SDK sources were removed in #332.

• pnpm-lock.yaml: regenerated with pnpm 10.34.5 (packageManager), so it only contains the remaining chart_data_extractor / template workspace projects and refreshed resolutions. The workspace minimumReleaseAge policy in pnpm-workspace.yaml was left untouched and applied during resolution.
• chart_data_extractor/poetry.lock: regenerated with Poetry 2.2.1 (poetry lock --regenerate); only marker normalization (python_version < "3.11" → == "3.10") and the generator header changed — no dependency version moves.

Verified with pnpm install --frozen-lockfile --lockfile-only and poetry check --lock.

Link to Devin session: https://app.devin.ai/sessions/212fc0a6cddc471fa8a611d6865dd7ad
Requested by: @mishushakov

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[claude]

I reviewed this PR and didn't find any bugs, but because it's purely a lockfile regeneration a human look would still be worthwhile to confirm the outcome matches the stated intent.

What was reviewed: the two regenerated lockfiles (pnpm-lock.yaml, chart_data_extractor/poetry.lock) and their consistency with the existing manifests (package.json, pyproject.toml). Checked the poetry.lock diff for the claimed marker-only normalization (python_version < "3.11" -> == "3.10") — confirmed no dependency version changes there. On the pnpm side, pnpm-lock.yaml resolves typescript from 5.7.3 to 7.0.2 (a brand-new major, native-rewrite release) purely because @ typescript-eslint/eslint-plugin/parser@ 7.18.0 declare typescript: '*' as a floating peer dependency — this isn't mentioned in the PR description and @ typescript-eslint@ 7.18.0 predates TS 7, so it's worth a human sanity-check that lint/type-check still behave as expected under the new compiler.

Extended reasoning...

Overview

The diff is limited to two regenerated dependency lock files — pnpm-lock.yaml (pnpm workspace, JS/TS deps) and chart_data_extractor/poetry.lock (Python deps) — with no source, config, or manifest changes. The stated purpose is a clean lockfile refresh after SDK sources were removed in a prior PR.

Security risks

No direct security risk from source-code changes since none exist. The main indirect risk is supply-chain related: lockfile regeneration can silently pull in new major versions via floating peer dependencies. I confirmed typescript jumped from 5.7.3 to 7.0.2 in pnpm-lock.yaml solely because @ typescript-eslint/eslint-plugin@ 7.18.0 and @ typescript-eslint/parser@ 7.18.0 specify typescript: '*' as a peer dependency, and pnpm resolved the wildcard to the newest release. The typescript@ 7.0.2 entry in the lockfile looks legitimate (has the expected hasBin, engines, and platform-specific @ typescript/typescript-* optional binaries consistent with the real native TypeScript 7 compiler rewrite), so this doesn't look like a malicious package, but it is an unpinned, unreviewed major-version jump for a package @ typescript-eslint@ 7.18.0 was never tested against.

Level of scrutiny

This warrants light-to-moderate scrutiny: the change is mechanical (lockfile regeneration) and the bug-hunting pass found no concrete bugs, but the unintended TypeScript major bump is the kind of side effect that's easy to miss in a "just regenerating locks" PR and could cause lint/type-check breakage in CI that isn't obvious from the diff alone.

Other factors

The PR author states pnpm install --frozen-lockfile --lockfile-only and poetry check --lock were run, which validates lockfile self-consistency but does not exercise the actual lint/build pipeline under the new TypeScript version. No third-party reviewer has raised objections yet, and two earlier bug-hunter passes flagged the same typescript version-jump concern but did not escalate it to a hard bug. Given that, and that it's outside the explicit change described, a brief human confirmation that CI (lint especially) still passes cleanly is the main added value here.