#423 vault put and read-secret use asymmetric path parsing; slash-put creates unreadable items

Summary

For the @swamp/1password provider, swamp vault put and swamp vault read-secret parse the <item>/<field> path differently. No single path syntax round-trips for a sectioned 1Password field, and using slashes in the field portion of put silently creates an item that cannot be read back via swamp.

Steps to reproduce

Any vault backed by @swamp/1password.

# A) Dot in field → put stores section=foo, field=bar (good)
swamp vault put my-vault my-item/foo.bar hello --force

# Read with same path → FAILS (op resolves as a literal field "foo.bar")
swamp vault read-secret my-vault my-item/foo.bar --force
#   Original error: item '.../my-item' does not have a field 'foo.bar'

# Read with slash → works (op resolves as section=foo, field=bar)
swamp vault read-secret my-vault my-item/foo/bar --force  # → "hello"

# B) Slash in field → put stores LITERAL label "foo/bar" (no section)
swamp vault put my-vault other-item/foo/bar hello --force
op item get other-item --vault <vault> --format json
#   "label": "foo/bar"   ← stored literally, in an unlabeled section

# Read of the slash-put item → FAILS by either syntax
swamp vault read-secret my-vault other-item/foo/bar --force
#   Original error: item '.../other-item' does not have a field 'foo.bar'
swamp vault read-secret my-vault other-item/foo.bar --force
#   (also fails — no literal "foo.bar" field)

Net effect:

• put X.Y + read X.Y → asymmetric (put works, read fails)
• put X.Y + read X/Y → works (but the two surfaces require different syntax)
• put X/Y + read X/Y → broken (item is created but unreadable)
• put X/Y + read X.Y → broken

The slash-put case is the worst: it silently creates a 1Password item that swamp itself cannot read back, with no warning to the user.

Expected

Pick one convention and use it on both sides, or accept both consistently:

1. Preferred: Treat the part after the first / as an opaque 1Password reference path (so item/section/field works for both put and read, matching op://vault/item/section/field). Either reject dots, or treat them as literal characters in the field label.
2. Alternative: Whatever syntax put accepts to denote a section, read-secret should accept the same syntax. (Currently put uses ., read uses /.)
3. At minimum: put should refuse a key whose resulting item cannot be read back by read-secret, rather than silently creating a broken item.

The docs (swamp extension search 1password) only describe item-name/field and the op://... passthrough — section-path syntax is undocumented in either direction.

Environment

• swamp 20260523.014309.0-sha.8ba74414
• @swamp/1password v2026.05.23.1
• 1Password CLI 2.x, desktop app integration on macOS

Workaround

Use flat field names only — no . or / in the field portion: my-item/bar instead of my-item/foo.bar. Round-trips cleanly.

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

• Extension: @swamp/1password@2026.05.23.1
• swamp: 20260523.014309.0-sha.8ba74414
• OS: darwin (aarch64)
• Deno: 2.7.14+19bd3d8
• Shell: /bin/zsh