Add Binect SDK implementation, Explorer, and test suite

SDK (@binect/js):
- BinectClient with domain sub-clients (documents, sendings, accounts,
  attachments, invoices)
- HTTP Basic Auth, native fetch only (no runtime dependencies)
- TypeScript types matching Binect API vocabulary
- Status predicates and polling helpers in helpers.ts
- Structured error handling (BinectApiError, BinectAuthError)

Explorer:
- Standalone browser-based API explorer (explorer/index.html)
- Interactive testing without code

Tests:
- Unit tests for client, types, errors, helpers, http
- E2E tests for upload/delete and send/cancel workflows

Also includes:
- Architecture Decision Records (ADRs)
- Example DIN 5008 letter PDFs for testing
- API specification research notes

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

architecture/ADR-001-sdk-architecture.md

@@ -0,0 +1,78 @@
+# ADR-001: SDK Architecture
+
+## Status
+Accepted
+
+## Context
+The Binect-JS SDK needs to provide a JavaScript/TypeScript wrapper for the Binect REST API. Per the PRD and TSD, the SDK must:
+- Be transparent and thin (no semantic reinterpretation)
+- Work in both browser and Node.js environments
+- Use domain-aligned sub-clients mirroring the API vocabulary
+- Separate core API layer from optional convenience helpers
+- Handle HTTP Basic Authentication without storing credentials
+
+## Decision
+
+### 1. Client Structure
+We adopt a **main client with domain-aligned sub-clients** pattern:
+
+```typescript
+const client = new BinectClient({ username, password });
+client.documents.upload(...)
+client.sendings.announce(...)
+client.attachments.list(...)
+client.accounts.get(...)
+client.invoices.list(...)
+```
+
+Each sub-client maps to an API domain and provides 1:1 method mapping to REST endpoints.
+
+### 2. HTTP Layer
+We use the native `fetch` API for HTTP requests:
+- Works in both browser and Node.js (>=18)
+- No external dependencies
+- Predictable behavior without hidden retries or timeouts
+
+### 3. Authentication
+- Credentials passed at client construction
+- Converted to Base64 Basic Auth header per request
+- Never stored beyond client instance lifetime
+- No automatic credential refresh
+
+### 4. Error Handling
+- Non-2xx responses throw `BinectApiError` with:
+  - HTTP status code
+  - Endpoint path
+  - Parsed response body (when available)
+- Network errors surface as-is (no wrapping)
+
+### 5. Type Safety
+- Full TypeScript types for all API requests/responses
+- Enums for document status, envelope types, franking types
+- Generic response types preserving API structure
+
+### 6. Convenience Layer (Optional)
+Additive helpers in separate modules:
+- Status predicates (`isShippable`, `isErroneous`)
+- Polling utilities (opt-in, no default behavior)
+- Response extractors
+
+These never replace core methods.
+
+## Consequences
+
+### Positive
+- Clear mental model mapping to API documentation
+- No hidden behavior or magic
+- Works in all JavaScript environments with fetch
+- Type-safe development experience
+
+### Negative
+- Developers must understand API structure
+- No automatic retry on transient failures (by design)
+- More verbose than heavily abstracted SDKs
+
+## References
+- PRD: Section 3.1 (Product Intent)
+- TSD: Section 3 (SDK Technical Orientation)
+- Binect API: https://app.binect.de/index.jsp?id=api

architecture/ADR-002-no-external-dependencies.md

@@ -0,0 +1,49 @@
+# ADR-002: No External Runtime Dependencies
+
+## Status
+Accepted
+
+## Context
+The SDK needs to make HTTP requests and handle authentication. Common approaches include using libraries like axios, node-fetch, or got for HTTP, and various utilities for base64 encoding.
+
+Per the TSD (Section 2, Design Guardrail #1): "No backend dependency - The product must function entirely in browser and JavaScript runtime environments."
+
+## Decision
+
+The SDK will have **zero runtime dependencies**:
+
+1. **HTTP Requests**: Use native `fetch` API
+   - Available in all modern browsers
+   - Built into Node.js >= 18
+   - No polyfills required for target environments
+
+2. **Base64 Encoding**: Use native APIs
+   - Browser: `btoa()` / `atob()`
+   - Node.js: `Buffer.from().toString('base64')`
+   - Provide isomorphic wrapper
+
+3. **Type Checking**: TypeScript (dev dependency only)
+
+## Consequences
+
+### Positive
+- No dependency vulnerabilities to manage
+- Smaller bundle size
+- Predictable behavior (no library-specific quirks)
+- Works identically in browser and Node.js
+- No version conflicts with consumer projects
+
+### Negative
+- Must implement utility functions ourselves
+- Cannot leverage library conveniences (interceptors, etc.)
+- Requires Node.js >= 18 (has native fetch)
+
+## Alternatives Considered
+
+1. **axios**: Popular but adds ~13KB and has had security vulnerabilities
+2. **node-fetch**: Would require different code paths for browser/Node
+3. **ky**: Modern but still an external dependency
+
+## References
+- TSD: Section 2 (Design Guardrails)
+- Node.js fetch: https://nodejs.org/docs/latest-v18.x/api/globals.html#fetch

architecture/ADR-003-explorer-architecture.md

@@ -0,0 +1,72 @@
+# ADR-003: Explorer Architecture
+
+## Status
+Accepted
+
+## Context
+The Binect Explorer needs to be a browser-based interactive tool for:
+- Learning the Binect API
+- Experimentation and evaluation
+- Safe testing before production integration
+
+Per the TSD (Section 4), the Explorer:
+- Must operate without server-side components
+- Must clearly distinguish between preview and send operations
+- Must require explicit confirmation for destructive actions
+- Is a learning tool, not an operations dashboard
+
+## Decision
+
+### 1. Technology Stack
+We use a **vanilla JavaScript/HTML/CSS** approach:
+- No framework dependencies (React, Vue, etc.)
+- Single HTML file with embedded CSS and JS
+- Can use the SDK directly via module import
+- Easy to host as a static file
+
+Rationale: Per TSD Section 7, the product must remain independent of specific UI frameworks. A vanilla approach ensures maximum portability and simplicity.
+
+### 2. Architecture Pattern
+**Component-based with vanilla JS**:
+- Modular JavaScript functions for each feature
+- Event-driven UI updates
+- State management via simple objects
+
+### 3. Feature Organization
+The Explorer UI is organized around the API domains:
+- **Credentials Panel**: Input and manage API credentials
+- **Documents Panel**: Upload, view, manage documents
+- **Sendings Panel**: Announce and track mail dispatch
+- **Attachments Panel**: Manage attachments
+- **Account Panel**: View account info and options
+
+### 4. Safety Features
+Per TSD requirements:
+- Credentials are ephemeral by default (cleared on page refresh)
+- Optional local storage for convenience (opt-in)
+- Send operations require explicit confirmation dialog
+- Preview available before sending
+- Clear visual distinction between safe (read) and destructive (send/delete) actions
+
+### 5. Use Case Profiles
+- Stored in browser localStorage
+- Export/import as JSON files
+- Contain only parameter configurations, not workflows
+
+## Consequences
+
+### Positive
+- Zero external dependencies
+- Works as single HTML file
+- Easy to understand and modify
+- Can be hosted anywhere (CDN, local file, etc.)
+- Aligns with TSD requirement for framework independence
+
+### Negative
+- Less sophisticated UI compared to framework-based apps
+- Manual DOM manipulation
+- No virtual DOM or reactive updates
+
+## References
+- TSD: Section 4 (Explorer Technical Orientation)
+- PRD: Section 4.1 (Functional Expectations)