fix: improve FunctionRegion type safety and API consistency

[grdsdev]

Summary

• Change FunctionRegion from enum to struct with RawRepresentable for better extensibility
• Add ExpressibleByStringLiteral conformance for improved ergonomics
• Update FunctionsClient to use FunctionRegion? instead of String? for type safety
• Remove duplicate initializers and @_disfavoredOverload annotations
• Update tests to work with new type structure

Previously, we maintained method overloads to accept both String (for regions not yet supported by the client) and FunctionRegion. With these changes, we now have a single FunctionRegion type that, due to its ExpressibleByStringLiteral conformance, allows passing any new region string, even if not yet supported by the client.

This eliminates the need for duplicate method overloads while maintaining the same functionality and improving type safety across the API.

Breaking Changes and Migration

This changes brings more maintainability for the codebase, but it may introduce some breaking changes dependending on how it is being used by customers.

• When using String from a variable and not a literal

let region = "custom-region"
try await functions.invoke(
  "hello",
  options: .init(region: region) // ❌ Compiler error
)

Solution

try await functions.invoke(
  "hello",
  options: .init(region: "custom-region") // ✅ Use literal string directly
)

Or

let region = "custom-region" as FunctionRegion // ✅ Cast string to FunctionRegion
try await functions.invoke(
  "hello",
  options: .init(region: region)
)

Test plan

• Run existing unit tests to ensure backward compatibility
• Verify function invocation with different regions still works
• Test string literal assignment to FunctionRegion works as expected

🤖 Generated with Claude Code