Branch name validation rejects '#' character, breaking Azure DevOps integration

[nxtShane]

Describe the bug
The Claude Code Action rejects branch names containing the # character, which is required by the standard Azure DevOps ↔ GitHub integration for ticket linking. This makes Claude Code Action incompatible with a standard, widely-used enterprise workflow.

Error
Action failed with error: Invalid branch name: "feature/AB#1992-sentry-enhancements". Branch names must start with an alphanumeric character and contain only alphanumeric characters, forward slashes, hyphens, underscores, or periods.

Root Cause
The validation logic inside claude-code-action is more restrictive than GitHub's own API, which does accept # in branch names. The error is generated client-side before any request reaches GitHub.

Context
The Azure DevOps + GitHub integration uses AB#<TICKET_ID> in branch names and PR titles to link work items across systems. This format is not configurable — it is the documented, idiomatic standard for that integration. Teams using both platforms have no alternative.

Impact
Teams using Claude Code Action alongside Azure DevOps are forced into one of three unacceptable options:

1. Run gh CLI manually — requires provisioning allowed bash commands, introducing security surface area
2. Break Azure DevOps ticket linking — defeats the purpose of the integration
3. Migrate to a different code review tool — significant team disruption

Expected behavior
Branch name validation should match GitHub's actual API rules, or be removed entirely in favor of letting GitHub's API surface errors if a name is truly invalid.

Steps to Reproduce

1. Set up the standard Azure DevOps ↔ GitHub integration
2. Create a branch following the required naming convention, e.g. feature/AB#1992-description
3. Trigger Claude Code Action on a PR from that branch
4. Observe validation failure

API Provider

[X] Anthropic First-Party API (default)
[ ] AWS Bedrock
[ ] GCP Vertex

Proposed Fix
Relax or remove the client-side branch name regex to allow #, aligning validation with GitHub's actual API constraints.

[nikp29]

slightly more comprehensive fix that addresses multiple similar issues tgt #1043