#141 obsidian-cli: base commands don't follow the documented file/path targeting rules

The File targeting section states that commands accept file or path, with file resolving "like a wikilink (name only, no path or extension needed)". Base commands do not follow that rule, and the resulting error messages point away from the actual cause.

Verified on Obsidian 1.13.7, macOS 26.6.2, against a vault whose root contains a single Tasks.base with two views.

Command	`file="Tasks"`	`file="Tasks.base"`	`path="Tasks.base"`	no target
`base:query`	✗ `Error: Base file not found: Tasks`	✓	✓	✗ `Error: Not a base file: <active>`
`base:views`	✗ `Error: Active file is not a base file: <active>`	✗ same	✗ same	✓ when a base is the active file

Two distinct issues:

file= requires the extension for bases. file="Tasks.base" works; bare file="Tasks" does not. So base targeting is exact-filename matching, not the wikilink resolution the skill documents.
base:views accepts no targeting at all. It ignores both file= and path= and always reads the active file. The error it returns names the active file, which reads as "you passed the wrong file" rather than "this command ignored your argument".

Repro

obsidian open path="Welcome.md"                          # any non-base file

obsidian base:views file="Tasks"                         # Error: Active file is not a base file: Welcome.md
obsidian base:views file="Tasks.base"                    # Error: Active file is not a base file: Welcome.md
obsidian base:views path="Tasks.base"                    # Error: Active file is not a base file: Welcome.md

obsidian base:query file="Tasks" view="Completed"        # Error: Base file not found: Tasks
obsidian base:query file="Tasks.base" view="Completed"   # works
obsidian base:query path="Tasks.base" view="Completed"   # works

Working invocations

obsidian base:query path="Tasks.base" view="Completed" format=csv
obsidian open path="Tasks.base" && obsidian base:views

Item 2 looks like a CLI limitation rather than anything the skill can change, so a note under File targeting covering both would probably be the right fix.

Unrelated minor note

dev:screenshot returns before the file is written and prints nothing on success, so an immediate ls looks like a silent failure. Step 3 of the develop/test cycle pairs it with dev:dom, which is synchronous, which makes the difference easy to miss. A one-line "wait before reading the file" would save someone the same detour. Relative paths resolve against the vault root; absolute paths also work.

Happy to send a PR for the doc changes if useful.