refactor(cli): introduce shared package metadata model

[Harsh-Sahu43]

Problem

Dora.toml metadata and registry metadata describe the same package semantics but are evolving independently.

If these paths define and validate package data independently, they can drift quickly as Project #2 grows. That would make later resolver, install, publish, and lockfile work harder to align.

Related context

This PR is aligned with the same package-management direction being explored in:

• #1451 — Dora.toml metadata validation
• #1453 — local registry index reader / inspect flow

What this PR changes

This PR introduces a shared package metadata model inside the CLI crate and makes both manifest and registry parsing normalize into it. This PR is intentionally scoped to the shared semantic layer and does not introduce new CLI surface.

Added

• a shared validated package model in binaries/cli/src/package_metadata.rs
• shared helpers for:
  • package/dependency name validation
  • semver parsing
  • entrypoint validation

Refactored

• binaries/cli/src/dora_toml.rs

  • keeps raw Dora.toml parsing separate
  • normalizes manifest metadata into the shared package model

• binaries/cli/src/registry.rs

  • keeps raw registry index parsing separate
  • normalizes registry package records into the same shared package model

Why this matters

This establishes a clean architectural foundation:

• Raw structs → file-oriented
• Shared model → semantic-oriented
• later layers like resolver, lockfile, install, and publish can build on one package model instead of multiple ad hoc ones

This prevents schema drift and ensures that future layers (resolver, lockfile, install, publish) operate on a single consistent package representation.

Design

Inspired by Cargo’s separation of concerns:

• parsing remains format-specific
• validation is centralized
• normalized package model is shared

Resolver and higher-level workflows are intentionally deferred.

Validation

cargo fmt --all --check
cargo check -p dora-cli
cargo test -p dora-cli package_metadata
cargo test -p dora-cli dora_toml
cargo test -p dora-cli registry
cargo clippy -p dora-cli --all-targets

[heyong4725]

Hi @Harsh-Sahu43, thanks for putting this together — the code itself is clean (PackageIdentity / PackageDefinition / DependencyRequirement is a reasonable shape, and the validator helpers are well-factored).

Closing this one as part of the broader call on the package-management track. Where the project is right now:

• Package management is a long-term roadmap item, not a near-term commitment. The final solution shape isn't clear yet, and we're not confident the community-visible value is there to justify the upfront design choices a package manager forces.
• Several adjacent PRs in this track were already closed (feat(cli): add Dora.toml metadata schema validation command #1451 Dora.toml validation, feat(cli): add local registry index reader and inspect command #1453 registry index reader). Without those merged consumers, the shared semantic layer here would land as ~569 lines of orphaned code with no callers — and the abstraction would harden a direction the project hasn't actually picked yet.
• RFC RFC: DORA Node Package Ecosystem (Manifest + Registry + Package Manager) #1402 will get the same treatment. When we revisit package management, we'd rather start from fresh thinking against whatever ecosystem reality looks like at that point, instead of carrying half-resolved foundation code forward.

This is not a quality judgment on the work — closing it on direction, not merit. Your other contributions are exactly the kind we want:

• feat(doctor): add /dev/shm permission check on Linux (rescue of #1352) #1818 (rescue of feat(cli) : add system doctor command with shared memory feature #1352, dora doctor /dev/shm permission check) merged 2026-05-14
• feat(uv): per-node managed Python venvs at build + runtime (rescue of #1515) #1820 (rescue of Prototype Dora-managed Python isolation for build and runtime #1515, per-node managed Python venvs) merged 2026-05-15

Both landed cleanly because they tackled concrete pain the project already had. If you're looking for the next thing to work on, the patterns that rescue well are: defensive fixes for crashes / panics, gaps in cross-platform CI, missing CLI ergonomics, and edge cases in existing features. The recent rescue stack (#1855, #1859, #1861, #1864, #1865, #1869, #1870) is a good shape to mirror.

Thanks again — please don't read this close as "stop contributing." Just "the foundation isn't laid here yet."