GET-004: be:// path → store resolution (userinfo home, .be default, non-hidden *.be, worktree)

GET-003 fixed the empty-path case; this ticket specifies the full be:// path→store resolution (authoritative semantics from the user). For be://[user@]host[/path]: the userinfo selects the peer home (be://gritzko@localhost/home/gritzko, default = the ssh-login user); an empty path denotes that home's hidden default store <home>/.be (GET-003); a non-empty path is HOME-relative with one uniform rule — a path ending in .be is the store itself (be://localhost/store.be$HOME/store.be, the *.git analogue), and any other path gets /.be appended (be://localhost/src/beagle$HOME/src/beagle/.be), where that .be resolves whether it is a directory (a store) or a file (a worktree pointer) — it does not matter which. Today keeper resolves a pathless ?/proj via a cwd walk-up from the login HOME to <home>/.be (GET-003) and a worktree/pathful form already negotiates (be://localhost/beagle?), but the explicit <path>/.be append, the *.be named-store form, and the user@ → home selection are unspecified/unverified. See GET, URI, blog/uris.mkd, CLAUDE.

Issues

The path slot of a be:// URL means "which store on the peer", but only two of the four cases are wired.

Blockers

Builds on GET-003 (the empty-path/.be base case) — land that first. Pure server-side store-resolution; no client grammar change beyond GET-003.

Planned

Specify and implement the four-case be:// path→store resolution; verify each against a hermetic peer.