V1: Define standalone ESP firmware user and code model

[mastertape]

Roadmap reference: docs/roadmap/dhl-paketkasten-retrofit-v1.md

Define the first standalone firmware data model for local users, codes and carrier/service-provider access.

Acceptance criteria:

• Model supports up to 10 users.
• Each user can have up to 5 codes.
• 1 master/admin code is represented.
• Up to 5 carrier/service-provider codes are represented.
• Household/group capability is included in the model from the beginning.
• Owner pickup/admin access and carrier deposit access are separated semantically.
• Offline validation behavior is described.
• Raw secret handling and audit/event logging assumptions are documented.
• Future bridge/cloud sync is not required but is not blocked by the model.

References:

• docs/access-control/opening-rights.md
• docs/roadmap/dhl-paketkasten-retrofit-v1.md

[mastertape]

Progress update:

A first keyring and delegated-key model has been documented:

• docs/access-control/keyring-model.md
• docs/security/remote-command-security.md

The model captures the current direction:

• credentials are not identities
• users/carriers/integrations are actors with stable local IDs
• credentials resolve to keys, keys resolve to actors and scopes
• master credentials stay local and can authorize scoped subkeys/integration keys
• Home Assistant/Matter/Bridge style integrations should receive scoped integration keys, not master credentials
• remote commands require authenticated transport plus rotating command authorization bound to device/action/time/request id
• offline revocation should use short validity, generations, local revocation lists and sync/update paths, similar in spirit to hotel lock systems

This issue should stay open until the M1 user/code model is reduced to concrete firmware data structures and acceptance tests.