feat(project): scaffold project manager interface

[Hweinstock]

Problem

We are currently missing a way to create and find existing projects on the local filesystem.

Solution

• add ProjectManager interface to core interface with stub implementations.
• migrate core input to a config object instead of positional arguments.
• design re-usable withProject middleware for commands that requires an existing project.

Note: this PR does not implement e2e functionality, but sets up the scaffolding for future contributions.

We'll likely want a working create command before filling in all of these gaps.

Verification

• added placeholder unit tests.
• running agentcore project create --> Error: ProjectManager.create is not implemented yet

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.94%. Comparing base (951044e) to head (bfaf476).

Additional details and impacted files

@@             Coverage Diff              @@
##           refactor    #1794      +/-   ##
============================================
+ Coverage     93.91%   93.94%   +0.02%     
============================================
  Files           118      122       +4     
  Lines          6423     6453      +30     
============================================
+ Hits           6032     6062      +30     
  Misses          391      391              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tejaskash]

I like that its available and injected through core.

[tejaskash]

LGTM, 1 clarification, not blocking

[AlexanderRichey]

I think this should be a type and not an interface. Interfaces are used for things that can have multiple implementations, whereas types require specific, concrete/instantiated entities. That's what we need here for the input params for this constructor, so a standard type seems more appropriate.

[Hweinstock]

I've always preferred interfaces to types since they tend to provide better error messages, and leave the door open if we want to extend them later on. The typescript language docs appear to recommend interfaces as the default here, but I do not have a strong preference here, especially since its very unlikely we'll want to extend these shapes.

I'll make the swap to types here.

[AlexanderRichey]

There's an important distinction between types and interfaces that I think we should respect here. Types hold data of a determinate form. They're not implemented by anything else—they are the thing. They are, in this way, concrete. Interfaces, in contrast, are abstract; they don't have a concrete existence. They must be implemented and instantiated by something else that is concrete. In the case here, what we want is a concrete input with data, which makes a type the right tool for the current job. Making this an interface would bring in a bunch of unnecessary functionality and, as you said, make it possible to extend, which is precisely what we wouldn't want in this case.

[AlexanderRichey]

Like the above, this should be a type.

[Hweinstock]

Updated implementation to treat project as data instead of an interface. ProjectManager will host all project functionality.