Tolerate cameras that serve a reduced PTP property set

[igor]

What

Three changes so Filmcase works on bodies that serve a reduced PTP property set. Found on an X-E5, but the second and third are not specific to it.

Why

Camera identity failed outright. camera_info() already falls back to 0 for FirmwareVersion, which the X-S10 does not serve. The X-E5 declines PROP_BATTERY and USBMode the same way, and those two reads were not guarded, so every read of camera identity raised on that body. This extends the existing fallback to cover them.

Slot reads reported fiction. Per-property reads fall back to "" for the slot name and 0 for the film simulation. A body that cannot reach C1–Cn therefore answers a scan with a complete set of blank slots, which is indistinguishable from a camera whose slots are genuinely empty. On the X-E5, camera_info --slots printed seven slots that do not exist.

The fix asks GetDeviceInfo whether the slot cursor is advertised. When it is definitely absent, the scan is skipped and the command says so. An empty property list is treated as unknown rather than unsupported, so the older bodies that answer GetDeviceInfo with nothing keep exactly the behaviour they have today.

A protocol gap. LibFujiDevice already implements supported_properties(), but PTPDevice did not declare it, so the domain layer could not call it under mypy. Declared, and added to the test fake.

Commits

1. Declare supported_properties on the PTPDevice protocol
2. Tolerate cameras that do not serve battery or USB mode
3. Skip the custom-slot scan on bodies without the slot cursor

Testing

• tests/unit/domain/camera/test_camera_info_tolerance.py — identity reads with each status property missing, and with all three missing
• tests/unit/domain/camera/test_supports_custom_slots.py — cursor advertised, absent, and unknown
• tests/integration/application/camera/test_get_camera_status.py — the scan is skipped when the cursor is absent, still runs when it is advertised, and still runs when support is unknown

mypy is clean on every changed file. The camera test suites pass locally. The full suite needs the PostgreSQL install, which I do not have set up, so I am relying on CI for the rest — hence draft.

Verified against a physical X-E5. I do not have other bodies to test on; the unsupported-cursor path is exercised through the fake.

Not included

I also have local management commands (camera_probe, camera_dump_slot, a CLI push_recipe) built while working this out. They are new surface area rather than fixes, so I have left them out to keep this reviewable. Happy to open a separate PR if they would be useful.

[igor]

Marking this ready. Notes on what I was and wasn't able to verify, since I don't have the full install.

I ran the suite on main and on this branch with the same (SQLite, no PostgreSQL) setup:

	passed	errors
main	933	1483
this branch	946	1483

The 1483 errors are identical on both — every DB-backed test failing at ensure_connection because there's no PostgreSQL here. The +13 are exactly the tests this PR adds. So nothing that can run in this environment regressed, and the new tests pass.

Not verified: the DB-backed tests. None of them touch camera code, but I can't claim they're green.

mypy is clean on every changed file. The X-E5 behaviour was confirmed against the physical body; the unsupported-cursor path is exercised through FakePTPDevice since I only have the one camera.

Happy to adjust anything, including splitting commit 1 out if you'd rather take the protocol declaration separately.

[gosku]

Thanks for the PR, the write-up made this easy to dig into.

Before I review it properly I want to confirm the changes are needed. Reading camera info is the least of it: if the X-E5 genuinely has no slot cursor, we can't push recipes to it at all, which matters more than anything in this PR.

I suspect the camera might be in the wrong USB mode: on my X-S10, card reader and tether both refuse properties that RAW CONV serves, the slot cursor among them. Could you check it's set to MENU → CONNECTION SETTING → USB SETTING → USB RAW CONV./BACKUP RESTORE?

I also put a camera_probe command on camera-usb-mode-diagnostics:

git fetch https://github.com/gosku/Filmcase.git camera-usb-mode-diagnostics
git checkout FETCH_HEAD
python manage.py camera_probe

Run it once per mode and it'll show which one advertises the slot cursor.

[gosku]

The 1483 errors are identical on both — every DB-backed test failing at ensure_connection because there's no PostgreSQL here. The +13 are exactly the tests this PR adds. So nothing that can run in this environment regressed, and the new tests pass.

Not verified: the DB-backed tests. None of them touch camera code, but I can't claim they're green.

tests/pytest_plugin_settings_isolation.py points FILMCASE_ENV_FILE at /dev/null so every setting falls back to its declared default, and DB_ENGINE defaults to PostgreSQL. So the 1483 errors are the suite looking for a PostgreSQL instance that isn't running, not SQLite refusing to serve them.

That's deliberate, so local runs and CI resolve to the same database, and it's why the README puts the full install under "for development".

Easiest fix is real environment variables to take precedence over that plugin:

DB_ENGINE=django.db.backends.sqlite3 DB_NAME=/tmp/test.sqlite3 pytest

That gets you 2409 passing. Seven will still fail regardless: the settings-conflict tests rely on a unique constraint with nulls_distinct, which SQLite doesn't support.