What this PR does / why we need it

feast init accepts a positional PROJECT_DIRECTORY argument, but passing a path currently fails:

$ feast init /tmp/test
Error: Invalid value for PROJECT_DIRECTORY: Name should be alphanumeric values,
underscores, and hyphens but not start with an underscore or hyphen.

The argument is validated as a project name (is_valid_name), so any path separator (/, \) is rejected — even though the argument is literally named PROJECT_DIRECTORY and users reasonably expect to scaffold into a directory (e.g. feast init /tmp/test or feast init my/sub/dir).

Change

In init_repo, when PROJECT_DIRECTORY contains a path separator and no explicit --repo-path is provided, treat the argument as the target directory and derive the project name from its final path component. The derived name is then validated as before.

$ feast init /tmp/test        # creates repo at /tmp/test, project name "test"
$ feast init my/sub/dir       # creates repo at my/sub/dir, project name "dir"
$ feast init my_project       # unchanged
$ feast init /tmp/_bad        # still rejected: basename "_bad" is invalid

Behavior with an explicit --repo-path, and plain project names, is unchanged.

Which issue(s) this PR fixes

Fixes #6134

Testing

• Added test_repo_init_with_path_argument in sdk/python/tests/unit/local_feast_tests/test_init.py — runs feast init <path> via the CLI runner and asserts the repo is scaffolded at the path with the project name derived from the basename.
• Verified the name-derivation + validation logic against the reporter's case and edge cases (/tmp/test → test; my/sub/dir → dir; /tmp/_bad still rejected; explicit --repo-path unchanged).

Note: I couldn't run the full test suite locally — import feast fails on my machine due to a pyarrow _substrait DLL being blocked by an OS Application-Control policy (unrelated to this change). The validation/derivation logic is small and pure, and the added regression test exercises the end-to-end CLI path in CI.