Hyphenated type names create phantom blobless type object during pull

[friedenberg]

Problem

When pulling objects whose type name contains a hyphen (e.g. ref-blob), the importer encounters a phantom type object matching the prefix before the hyphen (!ref) that has no blob digest. This triggers ErrBloblessTypeSkipped and fails the pull.

Reproduction

1. Init repo A, create a type named ref-blob (with [references] config), create a zettel of that type
2. Init repo B, pull from A with pull -direct <path> +zettel,typ,etikett
3. Pull fails with: blobless type definition skipped: object !ref type !toml-type-v1

The same workflow succeeds with refblob (no hyphen).

Error trace

blobless type definition skipped: object !ref type !toml-type-v1
├── # importer.Import
│   go/internal/romeo/remote_transfer/main.go:126
├── # importer.ImportSeq-range1
│   go/internal/romeo/remote_transfer/import.go:69
├── # (*Repo).pullQueryGroupFromWorkingCopy
│   go/internal/sierra/local_working_copy/local_op_pull.go:83

Analysis

The object !ref (genre Type, type !toml-type-v1) appears in the inventory list during pull but does not exist as a user-created object. It has a signature and public key but no blob digest. The !ref-blob type transfers successfully — the phantom !ref is an additional, unexpected object.

Likely causes to investigate:

• MakeInventoryList or expandEdges generating a truncated type ID from ref-blob → ref
• Hyphen parsing in SeqId.Set() or ObjectId.SetWithId() splitting ref-blob into components
• The source repo's commit or index creating !ref as a side effect when !ref-blob is used

Workaround

Use type names without hyphens (e.g. refblob instead of ref-blob).

Context

Discovered while writing pull_direct_blob_references_transferred integration test on the bright-holly branch (EdgeExplorer implementation for FDR-0001). The existing show_zettel_with_discovered_blob_references test in show.bats uses ref-blob without issue — the problem is specific to the pull/import path.

[friedenberg]

Fixed in 061af1b — removed expansion.ExpanderRight from addTypeAndExpandedIfNecessary. Follow-up deprecation and type inheritance design tracked in #43.