URL arguments with extra path segments act on the parent item #944

Found while reviewing #941.

urlarg.Parse (internal/urlarg/urlarg.go#L73) falls back to the SDK router's structural match, which matches a path prefix and ignores the segments that follow it. These are real bc3 pages:

• …/buckets/123/schedule_entries/456/occurrences/20261022/edit, the occurrence edit page, parses as entry 456 with no occurrence date.
• …/buckets/123/vaults/111/documents/456, a document under a folder, parses as folder 111.

So a command that takes <id|url> acts on the parent item, not the one the URL names. That includes recordings trash|archive|restore, spotlight and unspotlight. A user hits it by pasting an edit-page link. The result is a change to the wrong item, which can be undone.

Suggested fix: make Parse reject, or return nil for, a URL whose path has segments past the item the router matched, other than known suffixes such as /edit mapped to the item they edit. That fixes every caller at once, instead of each command checking. Add table tests for the two URLs above.