fix: make process ID configurable to resolve Docker PID issue (#30)

[aevitas]

Summary

Fixes #30

In containerized environments such as Docker, the process ID of the entrypoint is almost always 1. Since FlakeId uses the process ID as part of its uniqueness composite (5 bits), every Dockerized instance shares the same process ID component, reducing the uniqueness space and risking collisions when running multiple containers.

This PR introduces two ways to configure a custom process ID:

1. Static Property (Id.ProcessId)

// Set at application startup, before any IDs are generated:
Id.ProcessId = 7; // Must be in the range 0-31 (5 bits); values are automatically masked.

// Revert to automatic detection:
Id.ProcessId = null;

2. Environment Variable (FLAKEID_PROCESS_ID)

docker run -e FLAKEID_PROCESS_ID=7 my-app

Resolution Precedence

When multiple sources are configured, the process ID is resolved in the following order:

1. The value set through Id.ProcessId
2. The FLAKEID_PROCESS_ID environment variable
3. The OS-assigned process ID (existing behavior — unchanged)

The resolved value is masked to 5 bits (range 0–31) as before.

Changes

• src/FlakeId/Id.cs

  • Added s_configuredProcessId static field.
  • Added ProcessIdEnvironmentVariable internal constant ("FLAKEID_PROCESS_ID").
  • Added public static ProcessId property (get/set) with XML documentation.
  • Extracted process ID resolution into a new ResolveProcessId() private method that checks the property → env var → OS PID.
  • All existing comments and documentation are preserved.

• README.md

  • Added a new "Process ID Configuration" section between "Timestamps" and "Why create FlakeId?" documenting both configuration methods and the precedence rules.
  • All existing content is preserved.

• src/FlakeId.Tests/ProcessIdTests.cs (new file)

  • ProcessId_WhenSet_IsUsedInIdGeneration — verifies the configured PID appears in generated IDs.
  • ProcessId_WhenSetToNull_FallsBackToOsProcessId — verifies fallback to OS PID.
  • ProcessId_WhenSetOutOfRange_IsMaskedCorrectly — verifies values exceeding 5 bits are masked (e.g., 100 & 31 = 4).
  • ProcessId_WhenSetViaEnvironmentVariable_IsUsedInIdGeneration — verifies env var is picked up.
  • ProcessId_WhenSetViaProperty_TakesPrecedenceOverEnvironmentVariable — verifies precedence.
  • ProcessId_Get_ReturnsConfiguredValue — verifies the getter returns what was set.
  • Test cleanup restores original ProcessId and env var state, and resets internal s_prevId / s_processId caches.

• .gitattributes (new file)

  • Added * text=auto eol=lf to normalize line endings across the repository. This prevents future line-ending diff noise.

⚠️ Note on Id.cs Diff

The original Id.cs on master uses CRLF (Windows) line endings, while the content pushed through the GitHub API uses LF (Unix) line endings. This causes the diff to show every line as changed (-/+), even though most lines are identical.

The actual code changes in Id.cs are only:

1. New field — s_configuredProcessId (with 3 comment lines)
2. New constant — ProcessIdEnvironmentVariable (with 2 comment lines)
3. New property — ProcessId get/set (with XML doc comments)
4. One line changed in CreateInternal() — Process.GetCurrentProcess().Id & ProcessIdMask → ResolveProcessId()
5. New method — ResolveProcessId() (with XML doc comments)

That's ~40 lines of actual additions and 1 changed line out of the 278-line file. The rest is purely a CRLF → LF line-ending conversion.

The .gitattributes file added in this PR will prevent this issue for all future commits.

Backward Compatibility

This is a non-breaking change:

• If neither the property nor the environment variable is set, behavior is identical to before (OS process ID is used).
• The new ProcessId property defaults to null, meaning no configuration is required for existing users.
• No existing public APIs are changed.