Unknown field names silently dropped on `lpass add`/`edit` for typed secure notes

[LuL1ll0]

When creating or editing a typed secure note (e.g. wifi, server) non-interactively, any field name in stdin that doesn't match the note type's canonical schema is silently discarded with no warning. Compounding this, the canonical field names for each note type are not documented in --help or anywhere in the project, forcing users to reverse-engineer them by populating an entry via the GUI and inspecting it with lpass show --all.

Steps to reproduce:

lpass add "Test" --note-type=wifi --non-interactive << 'EOF2'
Network Name: MyNetwork
Password: hunter2
EOF2
lpass show --all "Test"

Expected: error indicating Network Name is not a valid field for wifi, OR success populating an SSID field.
Actual: note created with NoteType set, all fields blank, no error.

Suggested fixes: (a) document the canonical field names for each note type; (b) emit a warning when unknown field names are passed.

Version: lpass 1.6.1.6.g667da1f, macOS 15.

[LuL1ll0]

Update from further testing: the related Rust reimplementation jeduardo/lastpass-rs handles this case more gracefully — unknown field names are preserved as custom fields on the entry rather than being silently dropped. Same input that loses data with the C client retains it there.

Concrete test using the same input from the original report:

lpass add "Test" --note-type=wifi --non-interactive << 'EOF2'
Network Name: MyNetwork
Password: hunter2
EOF2

• C client: entry created, both fields blank, no warning
• lastpass-rs: entry created, Network Name: MyNetwork and Password: hunter2 both stored as fields, no warning

Either approach (preserve as custom field, or warn-and-reject) would be a meaningful improvement over silent data loss. The Rust implementation may be a useful reference if anyone picks this up.