Bump version to 0.0.35 to trigger PyPI publish

[GuanyiLi-Craig]

Why

The 0.0.35 release was cut (GitHub tag + release exist), but grafi==0.0.35 was never published to PyPI. PyPI is still on 0.0.34.

The release pipeline in .github/workflows/ci.yaml publishes to PyPI only when the version in pyproject.toml differs from the version already on PyPI, on pushes to main:

publish_pypi:
  if: github.ref == 'refs/heads/main' && needs.version.outputs.package-version != needs.version.outputs.remote-version
github_release:
  needs: [publish_pypi, version]

On the #98 merge to main, pyproject.toml still read 0.0.34 (== the PyPI version), so:

success   Get Package Version
skipped   Publish to PyPI      ← version == PyPI version
skipped   Github Release       ← needs: publish_pypi (skipped ⇒ skipped)

The manually-cut tag/release couldn't publish either: the tag 0.0.35 doesn't match the workflow's v*.*.* tag trigger, and the publish jobs are all gated on github.ref == 'refs/heads/main'.

What this does

Bumps pyproject.toml and uv.lock from 0.0.34 → 0.0.35. Once merged to main, CI will detect 0.0.35 != 0.0.34 and publish grafi 0.0.35 to PyPI. The existing GitHub release is preserved (github_release uses skipIfReleaseExists: true).

Follow-ups (not in this PR)

• Decouple github_release from publish_pypi so a skipped publish doesn't also skip the release.
• Surface a clear "version unchanged, nothing published" signal instead of silently skipping, so a merge that publishes nothing doesn't look fully successful.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.