Decorator-Driven Command Registry for abstract Instrument Server

Transition the AbstractInstrumentServer from a manual dictionary-lookup registration to decorator-based command system (@register_command). This refactor simplifies subclassing, enforces formatting validation and eliminates repetitive boilerplate code.

### Goals
Acceptance criteria : What journeys should the user be able to complete to consider your feature done
Be as specific as you can, check them off once they work. Add more if you find more requirements during development. Issue should only be considered done after all of them are checked
- [x] Decorator Availability: Developers can import register_command directly from the server module.
- [x] Subclassing: Subclasses of AbstractInstrumentServer can register custom hardware commands simply by decorating their methods (e.g., @register_command(b"my_command")).
- [x] No Manual Registry Updates: Developers no longer need to manually edit self._command_registry in the subclass __init__ or override the base constructor just to map commands.
- [x] No Overwrites: If a decorated subclass method attempts to register a command string that is already taken, it will raise exception.
- [x] Validation : The decorator should rejects invalid command formats (e.g., non-bytes, strings with spaces/tabs) immediately upon class loading.

### Tasks
base on the goals, deduce the tasks required. check them off once they're done
- [ ]
- [ ]
- [ ]
- [ ]
- [ ]

### Related Resources
any images/gifs, mockups/wireframes that would aid the development should be listed here
MockUp : `link to mockup`
Coda doc: `link to coda`
**Additional context**
Add any other context or screenshots about the feature request here.