Bump version to 0.3.3 and integrate API documentation (#28)

- Update api.jl to use api() function instead of api_overview()
- Fix GenericFluor parameter defaults in api_overview.md documentation
- Update module docstring to reference new api() function
- Improve API documentation integration

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-authored-by: Claude <noreply@anthropic.com>

Author: kalidke

.claude/commands/gen_api_overview.md

@@ -0,0 +1,165 @@
+# Create an API Overview File for This Julia Package
+
+Please generate an API overview document for this Julia package that will serve both human users and AI assistants. Follow the structure and guidelines below.
+
+## Step 1: Create an API Overview File
+
+Create a file named `api.md` in the root directory of your package:
+
+```
+YourPackage/
+├── src/
+├── test/
+├── docs/
+├── Project.toml
+├── README.md
+└── api.md  <- Create this file
+```
+
+This file should contain a concise, structured overview of your package's API with examples. Organize it with clear markdown headings (use ## for sections).
+
+## Why Create an API Overview?
+
+### For Humans
+- Provides a **concise reference** without diving into full documentation
+- Offers **quick-start examples** for common use cases
+- Shows **relevant patterns** more clearly than individual docstrings
+- Creates an **at-a-glance understanding** of package capabilities
+- Complements detailed documentation with a **higher-level view**
+
+### For AI Assistants
+- Enables **better code generation** with correct API patterns
+- Provides **structured context** about type hierarchies and relationships
+- Offers **consistent examples** to learn from when generating code
+- Creates **clear patterns** to follow when suggesting package usage
+- Helps avoid **common pitfalls** or misunderstandings about the API
+
+## What to Include in Your API Overview
+
+### 1. Key Concepts
+- Brief explanation of the core concepts and terminology
+- Domain-specific information necessary to understand the API
+- Important conventions (units, coordinate systems, defaults)
+
+### 2. Type Hierarchy
+- Visual representation of main types and their relationships
+- Clear indication of abstract vs. concrete types
+- Type parameters and their meaning
+
+### 3. Essential Types
+- Type definitions for most important types
+- Field documentation with types and purpose
+- Comments on mutable vs. immutable choices
+
+### 4. Constructor Examples
+- Common ways to instantiate key types
+- Parameter patterns and naming conventions
+- Default values and optional parameters
+
+### 5. Core Functions
+- Main functions grouped by purpose
+- Input/output patterns
+- Common parameter combinations
+
+### 6. Common Workflows
+- Step-by-step examples of typical usage patterns
+- Multiple approaches to solving common problems
+- Integration examples showing how components work together
+
+### 7. Complete Examples
+- Full working examples demonstrating end-to-end usage
+- Comments explaining each step
+- Sample output where appropriate
+
+## Writing Style Best Practices
+
+1. **Be Concise**: Prioritize brevity and clarity over exhaustive coverage
+2. **Use Consistent Formatting**: Maintain consistent structure for similar items
+3. **Focus on Patterns**: Highlight patterns that can be generalized
+4. **Include Type Information**: Make types explicit in examples and descriptions
+5. **Comment Liberally**: Include comments in code examples explaining parameter purposes
+6. **Use Clear Section Headers**: Make the document easily scannable with descriptive headers
+7. **Show Don't Tell**: Prefer concrete examples over abstract descriptions
+8. **Include Important Gotchas**: Note common pitfalls or non-obvious behaviors
+
+## Formatting Guidelines
+
+### Markdown Structure
+- Use `#` for title
+- Use `##` for main sections
+- Use `###` for subsections
+- Use backticks for inline code
+- Use triple backticks for code blocks with language specifier
+- Use bold (`**text**`) for important concepts
+
+### Code Examples
+- Always specify the language for code blocks: ```julia
+- Use descriptive variable names
+- Include comments for non-obvious steps
+- Show both simple and complex cases
+- Align similar elements for readability
+- Include complete function calls with all parameters
+
+### Type Definitions
+- Include complete type definitions with field comments
+- Show type parameters explicitly
+- Indicate mutability clearly
+
+## Example Section: "Filtering Operations"
+
+Here's an example of how you might document filtering operations in your package:
+
+When writing your actual Markdown, you would use the following structure:
+
+- A level-2 heading: `## Filtering Operations`
+- A Julia code block (with triple backticks and "julia" language specifier)
+- Code examples with comments
+- A brief explanation text
+- A numbered list explaining key points
+
+Your code examples would look like this:
+
+```julia
+# Filter by emitter properties using @filter macro
+bright = @filter(smld, photons > 1000)
+precise = @filter(smld, σ_x < 0.02 && σ_y < 0.02)
+combined = @filter(smld, photons > 1000 && σ_x < 0.02)
+
+# Select frames
+frame_5 = filter_frames(smld, 5)                 # Single frame
+early_frames = filter_frames(smld, 1:10)         # Range of frames
+specific_frames = filter_frames(smld, [1,3,5,7]) # Specific frames
+
+# Select region of interest (ROI)
+# 2D ROI
+roi_2d = filter_roi(smld, 1.0:5.0, 2.0:6.0)      # x_range, y_range
+
+# 3D ROI (for 3D emitters only)
+roi_3d = filter_roi(smld, 1.0:5.0, 2.0:6.0, -1.0:1.0)  # x_range, y_range, z_range
+```
+
+Then follow with explanatory text like:
+
+"The package provides several approaches to filtering data:
+
+1. The `@filter` macro allows filtering by any emitter property using natural condition syntax
+2. `filter_frames` selects emitters from specific frames efficiently
+3. `filter_roi` selects emitters within spatial regions of interest"
+
+## Maintenance Tips
+
+1. **Update with API Changes**: Keep the overview in sync with API changes
+2. **Focus on Stability**: Emphasize stable, public API features
+3. **Revise Examples**: Update examples to reflect current best practices
+4. **Solicit Feedback**: Ask users which aspects need more examples
+5. **Compare with Usage**: Review real-world usage patterns and reflect them
+
+## How to Test Your Overview
+
+To ensure your API overview is effective:
+
+1. **Ask a New User**: Have someone unfamiliar with your package try using it with just the API documentation
+2. **Test Code Examples**: Verify all code examples run correctly
+3. **Check Patterns**: Ensure patterns shown are current best practices
+4. **Review for Completeness**: Confirm all essential functionality is represented
+5. **Check for AI Usability**: Verify AI assistants can successfully use the overview to generate correct code