feat(auth): ProfileManager for named multi-directory identity profiles

[LiranCohen]

Problem

@enbox/auth manages identities within a single data directory and vault. Applications that need named profiles with separate data directories (e.g. gitd's work/personal profile separation) must build their own profile management layer.

gitd implements this in src/profiles/config.ts (194 lines):

• Named profiles mapped to ~/.enbox/profiles/<name>/DATA/AGENT/
• Multi-source resolution: CLI flag -> env var -> git config -> global default -> single-profile fallback
• Profile CRUD (create, list, get, set active, remove)
• Per-repo profile overrides via git config

Proposal

Add ProfileManager to @enbox/auth:

import { ProfileManager } from '@enbox/auth';

const profiles = new ProfileManager({ baseDir: '~/.enbox/profiles' });

// Create and use profiles
await profiles.create({ name: 'work', did: '...' });
await profiles.setActive('work');
const active = profiles.resolve(); // respects env, config, default

// Get an AuthManager for the active profile
const auth = await profiles.getAuthManager({ password });

Source reference

• gitd/src/profiles/config.ts:1-194

Acceptance criteria

• Named profiles with separate data directories
• Profile resolution with configurable precedence
• Profile CRUD operations
• Creates AuthManager instances scoped to a profile's data directory
• Config persistence (JSON file or pluggable storage)

[LiranCohen]

Moving to gitd — as specified this is gitd's profile-management layer (named profiles, a ~/.enbox/profiles// filesystem layout, and CLI/env/git-config resolution precedence), which is app policy rather than a headless @enbox/auth concern. @enbox/auth already supports pointing an AuthManager at an arbitrary dataPath, which is the one library-worthy primitive here. If a minimal profile-resolution primitive is later wanted in @enbox/auth, file a focused issue for that slice.