fix: recipe calls starting with "open" or containing hyphens misparse (PT-23, PT-24)

[pbertsch]

Summary

PT-23: open is a reserved keyword for the built-in open the app/open link verbs, and the parser claimed any step starting with it unconditionally. A recipe literally named open most recent post fell into open's undocumented bare-selector fallback, which consumed just the next word as a selector and left the rest of the line to misparse as a second, stray, unknown recipe call.

Fixed by only treating open as the built-in verb when what follows actually matches one of its two documented forms (the app/app, or a link) via a backtracking lookahead; anything else now falls through to a normal recipe call, preserving the whole phrase as the call's name.

PT-24: the lexer tokenized a word-internal hyphen as its own standalone token unconditionally -- fine for a recipe definition (name comes from a quoted string, hyphen preserved as-is), but at the call site the name is built by rejoining bare word tokens with spaces, so the hyphen came back out padded ("looking - for"), and the two representations could never match for any hyphenated recipe name.

Fixed by keeping a hyphen directly between two word characters part of the same identifier token. A standalone hyphen (the negative sign in set location -33.8, 151.2) is unaffected -- it's only reached preceded by a space, never mid-identifier, so this lexer path never sees it.

Test plan

• go build ./..., go vet ./..., go test ./... all pass
• staticcheck ./... clean
• New parser tests for both fixes (TestParser_RecipeCallStartingWithOpen, TestParser_HyphenatedRecipeCall), plus a regression guard (TestParser_SetLocationNegativeCoordinates, TestParser_OpenLink) confirming the documented forms still work. Confirmed both new tests fail against the pre-fix code, reproducing the exact reported error shapes ({Verb:open ...} {Name:"recent post"...} and "create looking - for post <arg> <arg>").
• Real-device verification against a running app (iOS simulator) for both fixes -- confirmed the recipe body actually executes instead of failing as an unknown recipe call.